Re: binutils 2.27 breaking Google coredumper...?

[Paul Smith <paul at mad-scientist dot net>]

Hm.  For posterity, it appears that this patch fixes my issue:

https://github.com/Romain-Geissler/google-coredumper/commit/34e01372982ff23e4e7e8f254ec9e96207e1d64c

It allows the coredumper library to recognize RELRO-hardened ELF
binaries.  Looking at the NEWS for ld I can see:

Changes in 2.27:

* Add a configure option --enable-relro to decide whether -z relro should
  be enabled in ELF linker by default.  Default to yes for all Linux
  targets except FRV, HPPA, IA64 and MIPS.

So... that looks like it!


On Sun, 2016-10-23 at 21:38 -0400, Paul Smith wrote:
> FWIW, I don't think this is related to compressed debug sections,
> because if I try to add -gz=none to my compile line I get this error
> (from cc1plus):
> 
>   x86_64-generic-linux-gnu-g++: error: -gz is not supported in this configuration
> 
> (seems weird to get this when I explicitly said "none", but oh well).
> 
> Still searching for clues...
> 
> 
> On Sun, 2016-10-23 at 20:03 -0400, Paul Smith wrote:
> > Hi all.  Does anyone have any experience with Google coredumper library?
> >  It used to be available at Google Code but mostly there are a bunch of
> > GitHub repos holding the code.  Mine is:
> >   https://github.com/madscientist/google-coredumper
> > 
> > We use this library to catch any sort of core, including both invoked
> > from inside our code (assert/abort/unhandled exception/SEGV/etc.) and
> > also from outside our code (SIGABRT).  It doesn't require any system or
> > user settings (e.g., ulimit, /proc, etc.) to be changed to work
> > properly, and it also writes already-compressed cores which is very
> > handy.
> > 
> > We've been using it for years on our GNU/Linux code (running on
> > x86_64/amd64) with GCC 4.9.2 and binutils 2.25 (built myself from
> > source).  Now I'm attempting to upgrade our toolchain to GCC 6.2.0 and
> > binutils 2.27.
> > 
> > Everything went fine (as far as compilation, running, etc.) except I
> > realized that when I try to read a core created with the coredumper
> > library (using GDB 7.11) it can't be read; the stack traces of all the
> > threads are corrupted.  I tried with both ld.gold and ld.bfd (but it may
> > not be a linker issue anyway).  Most look like this:
> > 
> > Thread 14 (LWP 9584):
> > #0  0x00007f1620ad5d84 in ?? ()
> > #1  0x0000000000000000 in ?? ()
> > 
> > Thread 13 (LWP 9585):
> > #0  0x00007f1620ad5d84 in ?? ()
> > #1  0x0000000000000000 in ?? ()
> > 
> > Thread 12 (LWP 9587):
> > #0  0x00007f1620ad5d84 in ?? ()
> > #1  0x0000000000000000 in ?? ()
> > 
> > Thread 11 (LWP 9589):
> > #0  0x00007f1620ad5d84 in ?? ()
> > #1  0x0000000000000000 in ?? ()
> > 
> > Thread 10 (LWP 9592):
> > #0  0x00007f1620ad5d84 in ?? ()
> > #1  0x0000000000000000 in ?? ()
> > 
> > etc.
> > 
> > I then tried to rebuild my toolchain with GCC 6.2.0 but staying with
> > binutils 2.25, and my coredumps worked again with this combo.
> > 
> > So, it appears something changed about the way binutils works between
> > 2.25 and 2.27 that breaks Google coredumper.
> > 
> > I wonder if anyone here has any experience with this, or suggestions as
> > to where to look further or what types of things to experiment with.
> > 
> > I tried reading the various NEWS files in the binutils subdirectories
> > and the only one that jumped at me was compressed debug sections... but
> > maybe there are other things that could be involved?
> > 
> > Any suggestions, pointers, slaps upside the head, etc. would be greatly
> > appreciated...
> > 
> > Cheers!