From: Milian Wolff <milian.wolff@kdab.com>
To: elfutils-devel@sourceware.org
Cc: Mark Wielaard <mark@klomp.org>
Subject: Re: [PATCH] Also find CFI in sections of type SHT_X86_64_UNWIND
Date: Wed, 07 Nov 2018 09:03:00 -0000 [thread overview]
Message-ID: <6704910.BGFJc7X5JR@agathebauer> (raw)
In-Reply-To: <f8b7a2805eed658a3e8dfeb8b81d7f15653d838a.camel@klomp.org>
[-- Attachment #1: Type: text/plain, Size: 3051 bytes --]
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
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 3826 bytes --]
next prev parent reply other threads:[~2018-11-07 9:03 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-29 15:21 Milian Wolff
2018-11-04 23:04 ` Mark Wielaard
2018-11-05 23:13 ` Milian Wolff
2018-11-06 11:07 ` Mark Wielaard
2018-11-07 9:03 ` Milian Wolff [this message]
2018-11-09 16:57 ` Mark Wielaard
2018-11-10 23:29 ` Mark Wielaard
2018-11-13 21:19 ` Mark Wielaard
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6704910.BGFJc7X5JR@agathebauer \
--to=milian.wolff@kdab.com \
--cc=elfutils-devel@sourceware.org \
--cc=mark@klomp.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).