Re: GDB 15/16 crashing in add_thread_silent()

On Fri, 2025-11-14 at 15:29 -0500, Paul Smith via Gdb wrote:
> Anyway, Tom de Vries writes this in summary:
> 
> > I suppose this is fixable, but I'm not sure it's worth the effort
> > for
> > a core file that has such limited usability.
> 
> I don't know about his core, but my coredump definitely doesn't have
> limited usability, because when I use GDB 8.2 from Rocky Linux the
> core is fully usable in all respects: I can see all the threads and
> interact with them in all ways.

Following Tom's debugging steps (I really don't know much about what
sections should exist in a core file or what the format should be) I
see that there is a similar problem using objdump.

If I use the native objdump from Rocky Linux, version 2.30-125.el8_10,
I get these types of results for .reg2 (note, there are no .reg
sections in this core file):

  0 note0         00009bf4  0000000000000000  0000000000000000  00001bd0  2**0
                  CONTENTS, READONLY
  1 .auxv         00000150  0000000000000000  0000000000000000  00002074  2**3
                  CONTENTS
  2 .reg2/9168    00000210  0000000000000000  0000000000000000  00002374  2**2
                  CONTENTS
  3 .reg2         00000210  0000000000000000  0000000000000000  00002374  2**2
                  CONTENTS
  4 .reg2/9168    00000210  0000000000000000  0000000000000000  00002734  2**2
                  CONTENTS
  5 .reg2/9168    00000210  0000000000000000  0000000000000000  00002af4  2**2
                  CONTENTS
  6 .reg2/9168    00000210  0000000000000000  0000000000000000  00002eb4  2**2
                  CONTENTS
  7 .reg2/9168    00000210  0000000000000000  0000000000000000  00003274  2**2
                  CONTENTS
  ...
 40 .reg2/9168    00000210  0000000000000000  0000000000000000  0000ae34  2**2
                  CONTENTS
 41 .reg2/9168    00000210  0000000000000000  0000000000000000  0000b1f4  2**2
                  CONTENTS
 42 .reg2/9168    00000210  0000000000000000  0000000000000000  0000b5b4  2**2
                  CONTENTS
 43 load1         00000000  0000000000400000  0000000000000000  00010000  2**16
                  ALLOC, READONLY, CODE
  ...

But, if I use the latest objdump 2.43.1, I get very different results:

  0 note0         00009bf4  0000000000000000  0000000000000000  00001bd0  2**0
                  CONTENTS, READONLY
  1 .auxv         00000150  0000000000000000  0000000000000000  00002074  2**3
                  CONTENTS
  2 .reg2/0       00000210  0000000000000000  0000000000000000  00002374  2**2
                  CONTENTS
  3 .reg2         00000210  0000000000000000  0000000000000000  00002374  2**2
                  CONTENTS
  4 .reg2/0       00000210  0000000000000000  0000000000000000  00002734  2**2
                  CONTENTS
  5 .reg2/0       00000210  0000000000000000  0000000000000000  00002af4  2**2
                  CONTENTS
  6 .reg2/0       00000210  0000000000000000  0000000000000000  00002eb4  2**2
                  CONTENTS
  7 .reg2/0       00000210  0000000000000000  0000000000000000  00003274  2**2
                  CONTENTS
  ...
 40 .reg2/0       00000210  0000000000000000  0000000000000000  0000ae34  2**2
                  CONTENTS
 41 .reg2/0       00000210  0000000000000000  0000000000000000  0000b1f4  2**2
                  CONTENTS
 42 .reg2/0       00000210  0000000000000000  0000000000000000  0000b5b4  2**2
                  CONTENTS
 43 load1         01ae0000  0000000000400000  0000000000000000  00010000  2**16
                  ALLOC, READONLY, CODE
  ...

So, there appears to be some difference in binutils where it can't
parse this core file properly...?