[PATCH] llvm-readobj: add support for ARM EHABI unwind info

Logan Chien tzuhsiang.chien at gmail.com
Tue Jan 7 19:23:56 PST 2014



================
Comment at: tools/llvm-readobj/ARMEHABIPrinter.h:236
@@ +235,3 @@
+
+      PrintByteCode(Contents->slice(Entry * IndexTableEntrySize + 4, 3));
+    } else {
----------------
Saleem Abdulrasool wrote:
> Logan Chien wrote:
> > Should this be "(Entry * IndexTableEntrySize + 5)" instead?  The 0x80 itself is not an unwind opcode.
> No, it should be + 4 as is.The offset is to get to the second word.  The length of three is due to the fact that the first byte is not an actual unwind opcode (as you noted).
OK.  I forget that this word should be little endian.  BTW, it seems that line 151 is inconsistent.

================
Comment at: tools/llvm-readobj/ARMEHABIPrinter.h:149
@@ +148,3 @@
+
+    switch (PersonalityIndex) {
+    case AEABI_UNWIND_CPP_PR0:
----------------
Saleem Abdulrasool wrote:
> Logan Chien wrote:
> > In fact, the only possible personality index is 0.  For the other personality index, they should be placed in .ARM.extab section.  (It will be helpful to have a look to the personality1 test case which I have given above.)
> This is routine which parses the extab (and in fact, the current code parses it just fine).
Oops.  I didn't realize this function is for extab.  However, in this case, AEABI_UNWIND_CPP_PR0 will never be reached, which should be handled earlier in PrintIndexTable().  IMO, we should either change line 151 to llvm_unreachable() or call this function when __aeabi_unwind_cpp_pr0 is found in PrintIndexTable().

================
Comment at: tools/llvm-readobj/ARMEHABIPrinter.h:110
@@ +109,3 @@
+template <typename ET>
+void PrinterContext<ET>::PrintExceptionTable(const Elf_Shdr *IT,
+                                             const Elf_Shdr *EHT,
----------------
Is IT used in this function?

================
Comment at: tools/llvm-readobj/ARMEHABIPrinter.h:166
@@ +165,3 @@
+
+      PrintByteCode(ArrayRef<uint8_t>(ByteCode.begin(), ByteCode.end()));
+      break;
----------------
I feel that it will be better to reorder the opcodes before passing these to PrintByteCode().  For example, given the extab with following bytes:

    01,02,03,81    04,05,06,07    08,09,10,11    12,13,14,15

The correct unwind opcode decode order should be:

    02,01,07,06,05,04,11,10,09,08,15,14,13,12

However, we will pass:

    04,05,06,07,08,09,10,11,12,13,14,15,01,02

One tricky way is to use following code to create ByteCode array:

    const uint8_t *TableEntry = Contents->data() + TableEntryOffset;
    for (size_t i = 0, j = 1; i < ByteCode.size(); ++i, j = (((j ^ 0x3u) + 1) ^ 0x3u)) {
        ByteCode[i] = TableEntry[j];
    }

Or alternatively, we can change the PrintByteCode() interface.  We can simply pass the pointer to the first word and a start offset to PrintByteCode().  For example, I might implement PrintByteCode() with:

    template <typename ET>
    void PrinterContext<ET>::PrintByteCode(const uint8_t *ByteCode, size_t NumByteCode, size_t StartPos) {
      ListScope BC(SW, "ByteCode");
      for (unsigned i = 0, Pos = StartOffset; i < NumByteCode; ++i, Pos = (((Pos ^ 0x3u) + 1) ^ 0x3u)) {
        SW.printHex("Instruction", ByteCode[Pos]);
      }
    }

And then we can call this function with:

    PrintByteCode(Contents->data() + TableEntryOffset, 2 + 4 * AdditionalWords, 1);

This approach gives us an advantage that we don't have to create a new arrary to hold the reordered unwind opcodes.

================
Comment at: tools/llvm-readobj/ARMEHABIPrinter.h:180
@@ +179,3 @@
+template <typename ET>
+void PrinterContext<ET>::PrintByteCode(const ArrayRef<uint8_t> ByteCode) const {
+  ListScope BC(SW, "ByteCode");
----------------
IMO, I would suggest to use PrintUnwindInstructions() or PrintUnwindOpcodes().  "ByteCode" looks to general.


http://llvm-reviews.chandlerc.com/D2513



More information about the llvm-commits mailing list