Re: binutils 2.27 breaking Google coredumper...?

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

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!