Subject: Re: Kernel support for ELF-format core files
To: Andrew Cagney <cagney@mac.com>
From: Jason R Thorpe <thorpej@wasabisystems.com>
List: tech-kern
Date: 12/09/2001 23:16:56
On Sun, Dec 09, 2001 at 10:02:22PM -0800, Andrew Cagney wrote:

 > >  * "NetBSD-CORE@nn" (where nn is the lwpid of the LWP) for
 > > 	  notes that apply only to the specified LWP (e.g. register
 > > 	  contents).  Since the kernel on the trunk doesn't yet support
 > > 	  LWPs, these currently just look like "NetBSD-CORE@0".
 > > 
 > 
 > 
 > FYI, for light weight process registers, GDB (gdb/corelow.c) appears to 
 > expect ``.reg/<LWPID>'' and/or ``.reg''.

Yes, I know.  Those pseudo-sections are put together by libbfd.  The
number after the / is actually ((lwpid << 16) | pid).

The changes I made to libbfd put it all together in the convention
that gdb expects.

For example:

ections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 load0         00000000  08048000  00000000  00001000  2**0
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  1 load1         00001000  08049000  00000000  00001000  2**0
                  CONTENTS, ALLOC, LOAD
  2 load2         00000000  48049000  00000000  00002000  2**0
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  3 load3         00001000  48052000  00000000  00002000  2**0
                  CONTENTS, ALLOC, LOAD
  4 load4         00009000  48053000  00000000  00003000  2**0
                  CONTENTS, ALLOC, LOAD
  5 load5         00000000  4805c000  00000000  0000c000  2**0
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  6 load6         00005000  480e6000  00000000  0000c000  2**0
                  CONTENTS, ALLOC, LOAD
  7 load7         0000c000  480eb000  00000000  00011000  2**0
                  CONTENTS, ALLOC, LOAD
  8 load8         00002000  bfbfc000  00000000  0001d000  2**0
                  CONTENTS, ALLOC, LOAD, CODE
  9 note9         00000198  00000000  00000000  00000174  2**0
                  CONTENTS, READONLY
 10 .reg/304      00000040  00000000  00000000  00000244  2**2
                  CONTENTS
 11 .reg          00000040  00000000  00000000  00000244  2**2
                  CONTENTS
 12 .reg2/304     0000006c  00000000  00000000  000002a0  2**2
                  CONTENTS
 13 .reg2         0000006c  00000000  00000000  000002a0  2**2
                  CONTENTS

The "note9" section is other stuff that gdb doesn't need (and
thus libbfd doesn't create a pseudo-section for).

The code for all this is in bfd/elf.c -- I posted a diff to tech-toolchain
that implement support for all this.

 > For instance, on Solaris 2.5.1, examining a core file, I see:
 > 
 > 	.reg/90680
 > 		I suspect this is the primary thread
 > 
 > 	.reg	I think this is the same as .reg/90680
 > 		for compatability.
 > 
 > 	.reg2	contains the FP registers
 > 
 > 	.reg2/90680
 > 		contains the same FP registers

...note these are all > 64k ... using the convention that I described
earlier, this works out to a pid if 25144 and an lwpid of 1.  This
matches the convention we implemented[*].

[*] In the core file example I pasted above, the lwpid is 0, because
Nathan hadn't pointed out to me yet that lwpids start at 1 (it's correct
in the code I committed).

 > The really interesting thing is that it would appear that the first 
 > threaded core file support in GDB was added for LynxOS and not Solaris 
 > which suggests this is a common convention.
 > 
 > While I don't know where the 2 in .reg2 which contains the FP registers 
 > comes from, a guess is that 2+PT_GETREGS==PT_GETFPREGS has something to 
 > do with it.

The ".reg2" is actually just a hard-coded string in libbfd :-)  That might
have been where it originally came from, but it's not like it's constructed
from anything ...

-- 
        -- Jason R. Thorpe <thorpej@wasabisystems.com>