Re: [PATCH] Also find CFI in sections of type SHT_X86_64_UNWIND

[Milian Wolff <milian dot wolff at kdab dot com>]

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 | 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

Attachment: smime.p7s
Description: S/MIME cryptographic signature