In my last post I did a very basic comparsion of ARM code generation between LLVM and GCC compilers and testing the AXF in Qemu. The stand out difference was LLVM produced a *.ARM.exidx** section in the AXF/ELF while arm-gcc did not. The code is very simple, one .s and one .c file, no .cpp/.h involved.
So what is a .ARM.exidx section?
ARM ELF manual show this under the special sections chapter:
| Name |￼Type |￼Attributes | | - | - | - | | ARM.exidx |￼ SHT_ARM_EXIDX | SHF_ALLOC + SHF_LINK_ORDER | _
Names beginning .ARM.exidx name sections containing index entries for section unwinding. Names beginning .ARM.extab name sections containing exception unwinding information. See [EHABI] for details.
Table 4_4 from that manual shows the Processor specific section types and our attribute is:
| Name | Value | Comment | | - | - | - | | “SHT_ARM_EXIDX” | 0x70000001 | | _
So the question remains, what is in the section and what is being created? Lets dump HelloWorldSimple.o and only look at that section:
1 2 3 4 5 6 7
So it added both function calls to the table, but are marked cantunwind, which makes sense, but since nothing in the section can be unwound, why include the section? Using gc-sections during linking does not remove it as it has references to functions that are being used…
Let do a quick test and add -funwind-tables, recompile and yes we get a fully populated unwind table and using -fno-unwind-tables produces the results from above, so that is the default one that is being use. Research is on-going on this one…
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
Additional Reading: ARM unwind table linker processing; this concerns a patch to bintutils/ld:
The patch below implements linker processing of ARM unwinding tables (SHT_ARM_EXIDX).
ARM exception index tables only define the start address of each region. This means that code with no unwinding information is effectively covered by the preceding unwinding table entry.
For normal exceptions that doesn’t matter so much - the user should ensure that any code they throw exceptions through has proper unwinding information.
Just as a quick check, I grep’d some source and the *.ARM.exidx** section is generated by the ARMELFStreamer:
1 2 3 4 5 6 7 8
1 2 3