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

2018-11-07 Thread Milian Wolff
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 2004  2004
  [15] .eh_frame PROGBITS 2030  2030

$ /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_UNWIND0670  0670
  [15] .eh_frame_hdr X86_64_UNWIND0724  0724
```

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 

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


Elfutils new reelease

2018-11-07 Thread Karbownik, Anna
Hi,

I'd like to ask you whether you plan to release 0.175 elfutils version? 
If so, when are you going to announce it and will it contain all the master 
branch changes since 0.174 release (especially all the CVE security patches)?

Best regards,
Anna Karbownik



Re: Elfutils new release

2018-11-07 Thread Mark Wielaard
On Wed, 2018-11-07 at 14:15 +, Karbownik, Anna wrote:
> I'd like to ask you whether you plan to release 0.175 elfutils
> version? 

There are enough (small) new features and bug fixes to do a new
release. Lets aim for next week.

There are still a couple of patches cooking on the mailinglist and
there is one outstanding bug related to the new eu-strip --reloc-debug-
sections-only option with relocations against compressed debug sections
(but only on armhf and ppc64) which will need to be resolved.

> If so, when are you going to announce it

Once all patches are in and the bug is resolved. Hopefully end of this
week. I'll announce the intent to do a new 0.175 release on this
mailinglist. Then after a couple of days, I'll do the release unless
more issues are found. Hopefully somewhere next week.

>  and will it contain all the master branch changes since 0.174
> release (especially all the CVE security patches)?

Yes, the release will be made from the git master branch.

BTW. I don't think the new CVEs filed are really that important. Or at
least very low severity. The descriptions are very misleading. Some are
simply bugs that cannot be exploited. But it is of course always a good
idea to fix any bugs found.

Cheers,

Mark