On Montag, 22. Oktober 2018 15:58:17 CEST Andi Kleen wrote: > Milian Wolff writes: > > After more digging, it turns out that I've apparently chased a red > > herring. > > I'm running archlinux which isn't shipping debug symbols for libm. > > 64bit executables normally have unwind information even when stripped. > Unless someone forcefully stripped those too. > > You can checkout with objdump --sections. Right, we do have .eh_frame and .eh_frame_hdr according to readelf: ``` $ readelf --sections /usr/lib/libm.so.6 There are 26 section headers, starting at offset 0x183120: Section Headers: [Nr] Name Type Address Offset Size EntSize Flags Link Info Align [ 0] NULL 0000000000000000 00000000 0000000000000000 0000000000000000 0 0 0 [ 1] .note.gnu.build-i NOTE 0000000000000270 00000270 0000000000000024 0000000000000000 A 0 0 4 [ 2] .note.ABI-tag NOTE 0000000000000294 00000294 0000000000000020 0000000000000000 A 0 0 4 [ 3] .note.gnu.propert NOTE 00000000000002b8 000002b8 0000000000000020 0000000000000000 A 0 0 8 [ 4] .gnu.hash GNU_HASH 00000000000002d8 000002d8 00000000000024d0 0000000000000000 A 5 0 8 [ 5] .dynsym DYNSYM 00000000000027a8 000027a8 00000000000066c0 0000000000000018 A 6 1 8 [ 6] .dynstr STRTAB 0000000000008e68 00008e68 0000000000002352 0000000000000000 A 0 0 1 [ 7] .gnu.version VERSYM 000000000000b1ba 0000b1ba 0000000000000890 0000000000000002 A 5 0 2 [ 8] .gnu.version_d VERDEF 000000000000ba50 0000ba50 000000000000017c 0000000000000000 A 6 11 8 [ 9] .gnu.version_r VERNEED 000000000000bbd0 0000bbd0 0000000000000060 0000000000000000 A 6 2 8 [10] .rela.dyn RELA 000000000000bc30 0000bc30 0000000000000480 0000000000000018 A 5 0 8 [11] .init PROGBITS 000000000000d000 0000d000 000000000000001b 0000000000000000 AX 0 0 4 [12] .text PROGBITS 000000000000d020 0000d020 00000000000a063b 0000000000000000 AX 0 0 16 [13] .fini PROGBITS 00000000000ad65c 000ad65c 000000000000000d 0000000000000000 AX 0 0 4 [14] .rodata PROGBITS 00000000000ae000 000ae000 00000000000c76a4 0000000000000000 A 0 0 32 [15] .eh_frame_hdr PROGBITS 00000000001756a4 001756a4 0000000000001c34 0000000000000000 A 0 0 4 [16] .eh_frame PROGBITS 00000000001772d8 001772d8 00000000000093f0 0000000000000000 A 0 0 8 [17] .hash HASH 00000000001806c8 001806c8 000000000000210c 0000000000000004 A 5 0 8 [18] .init_array INIT_ARRAY 0000000000183c80 00182c80 0000000000000008 0000000000000008 WA 0 0 8 [19] .fini_array FINI_ARRAY 0000000000183c88 00182c88 0000000000000008 0000000000000008 WA 0 0 8 [20] .dynamic DYNAMIC 0000000000183c90 00182c90 00000000000001f0 0000000000000010 WA 6 0 8 [21] .got PROGBITS 0000000000183e80 00182e80 0000000000000180 0000000000000008 WA 0 0 8 [22] .data PROGBITS 0000000000184000 00183000 000000000000000c 0000000000000000 WA 0 0 8 [23] .bss NOBITS 000000000018400c 0018300c 000000000000000c 0000000000000000 WA 0 0 4 [24] .comment PROGBITS 0000000000000000 0018300c 000000000000001a 0000000000000001 MS 0 0 1 [25] .shstrtab STRTAB 0000000000000000 00183026 00000000000000fa 0000000000000000 0 0 1 Key to Flags: W (write), A (alloc), X (execute), M (merge), S (strings), I (info), L (link order), O (extra OS processing required), G (group), T (TLS), C (compressed), x (unknown), o (OS specific), E (exclude), l (large), p (processor specific) ``` But should that be enough information to be able to unwind from a function prologue? I mean, it obviously seems to work when we unwind from the function body. But how would I know whether it should work from the prologue too? Reading e.g. https://www.airs.com/blog/archives/460, I can find: > There should be exactly one FDE covering each instruction which may be being executed when an exception occurs. By default an exception can only occur during a function call or a throw. When using the -fnon-call-exceptions gcc option, an exception can also occur on most memory references and floating point operations. When using -fasynchronous-unwind-tables, the FDE will cover every instruction, to permit unwinding from a signal handler. So what if my libm wasn't compiled with -fasynchronous-unwind-tables? We probably cannot throw an exception in the function prologue, so potentially that range is simply not mapped? But this is just a shot in the dark, I have no clue how to get more information about what contents are actually stored in the .eh_frame section. I would love to find out though! Does anyone know a tool to sched some light into this section? I found http://www.bitlackeys.org/#eh_frame which at least shows me that __hypot_finite is mentioned in the .eh_frame section: $ nm -aD /usr/lib/libm.so.6 |& grep hypot_finite 0000000000029660 T __hypot_finite $ ./eh_frame /usr/lib/libm.so.6 |& grep 29660 Function size: 878 Function Addr: 29660 Thanks -- Milian Wolff | milian.wolff@kdab.com | Senior Software Engineer KDAB (Deutschland) GmbH, a KDAB Group company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts