This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: binutils 2.27 breaking Google coredumper...?
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!