[PATCH] Also find CFI in sections of type SHT_X86_64_UNWIND

Milian Wolff milian.wolff@kdab.com
Wed Nov 7 09:03:00 GMT 2018


On Dienstag, 6. November 2018 12:06:57 CET Mark Wielaard wrote:
> Hi Milian,
> 
> On Tue, 2018-11-06 at 00:12 +0100, Milian Wolff wrote:
> > On Montag, 5. November 2018 00:04:32 CET Mark Wielaard wrote:
> > 
> > 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 seems to only happen with a specific combination of gcc and the gold
> linker, I could only generate the SHT_X86_64_UNWIND sections only on
> fedora 29 with gcc 8.2.1 and gold version 2.31.1-13.fc29 (1.16).

At least on my system, that doesn't seem to be enough. Both my desktop and my 
laptop are running on ArchLinux with the same versions of GCC and Gold, yet 
one shows this behavior while the other one isn't...

What I noticed is that ccache seems to influence it for me, which makes this 
even stranger:

```
$ which gcc
/usr/lib/ccache/bin/gcc
$ gcc --version
gcc (GCC) 8.2.1 20180831
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ gcc test.c
$ readelf -S a.out | grep eh_frame
  [14] .eh_frame_hdr     PROGBITS         0000000000002004  00002004
  [15] .eh_frame         PROGBITS         0000000000002030  00002030

$ /usr/bin/gcc test.c
$ /usr/bin/gcc --version
gcc (GCC) 8.2.1 20180831
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ /usr/bin/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
```

Anyhow, that's unrelated to the patches at hand here. See below.

> > > - 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 :)
> 
> OK, then lets change your patch to do that as attached.
> 
> > > - 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:
>
> And the other attached patch should clean that up.

Both patches work for me:

    Tested-by: Milian Wolff <milian.wolff@kdab.com>

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3826 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/elfutils-devel/attachments/20181107/f57ca96b/attachment.p7s>


More information about the Elfutils-devel mailing list