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.wo...@kdab.com>
Thanks
--
Milian Wolff | milian.wo...@kdab.com | 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
