public inbox for elfutils@sourceware.org
 help / color / mirror / Atom feed
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 --]

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