On Montag, 5. November 2018 00:04:32 CET Mark Wielaard wrote:
> On Mon, 2018-10-29 at 16:21 +0100, Milian Wolff wrote:
> > On my system with g++ (GCC) 8.2.1 20180831 with GNU gold (GNU
> > Binutils
> > 2.31.1) 1.16, the .eh_frame section does not have type PROGBITS
>
> > but rather is using X86_64_UNWIND nowadays:
> Urgh, who thought it would be a good idea to have a architecture
> specific (instead of a GNU specific) section type for unwind tables...
> And why is there no separate type for .eh_frame_hdr. Now you still need
> to check the name anyway...
>
> But, given that we have that now, yes, lets deal with it.
>
> > ```
> > $ echo "int main(){ return 0; }" > test.c
> > $ gcc test.c
> > $ readelf --sections a.out | grep .eh_frame
> > [14] .eh_frame X86_64_UNWIND 0000000000000670 00000670
> > [15] .eh_frame_hdr X86_64_UNWIND 0000000000000724 00000724
> > ```
> >
> > Without this patch, libdw refuses to use the available unwind
> > information, leading to broken backtraces while unwinding. With the
> > patch applied, unwinding works once more in such situations.
>
> Three questions:
>
> - What testcase did you use?
> In theory dwarf_getcfi_elf () should fall back to using phdrs and
> find the PT_GNU_EH_FRAME data instead.For unwinding, I used this full example: https://paste.kde.org/p5rogntox Then I compiled with `g++ -g O2` and recorded it with perf (`perf record -- call-graph dwarf`). Finally, I looked at the unwinding results via `perf script`. I compiled perf from sources with `NO_LIBUNWIND=1` to have it use libdw instead. Interestingly, when I try to reproduce this on my laptop (i.e. compile even the trivial C example), then I cannot reproduce this at all anymore - the .eh_frame sections show up as PROGBITS. My desktop at work still shows this behavior though (also see below). I can't quite explain this difference... > - It might be better to change the check to shdr->sh_type != SHT_NOBITS > The idea is probably that we don't want to look at the data in case > this is a .debug file which has it removed. This might be better than > adding a check for X86_64_UNWIND since then we would also need to > check the arch. Does != SHT_NOBITS work for you? Yes, since SHT_NOBITS is not equal to SHT_X86_64_UNWIND :) > - What does eu-readelf -S show? > I think we need a x86_64_section_type_name () ebl hook to show it > correctly. Yes, that looks like it: ``` $ cat test.c int main() { return 0; } $ gcc test.c $ readelf -S a.out | grep eh_frame [14] .eh_frame X86_64_UNWIND 0000000000000670 00000670 [15] .eh_frame_hdr X86_64_UNWIND 0000000000000724 00000724 $ eu-readelf -S a.out | grep eh_frame [14] .eh_frame SHT_LOPROC+1 0000000000000670 00000670 000000b4 0 A 0 0 8 [15] .eh_frame_hdr SHT_LOPROC+1 0000000000000724 00000724 0000002c 0 A 0 0 4 ``` Cheers -- Milian Wolff | [email protected] | Senior Software Engineer KDAB (Deutschland) GmbH, a KDAB Group company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts
smime.p7s
Description: S/MIME cryptographic signature
