Re: [patch] solib-svr4.c - allow reading linkmap info from core without executable

[Pedro Alves <pedro@codesourcery.com>]

On Friday 19 June 2009 15:42:04, Mark Kettenis wrote:
> > From: Aleksandar Ristovski <aristovski@qnx.com>
> > Date:  Fri, 19 Jun 2009 10:16:26 -0400
> > 
> > Pedro Alves wrote:
> > > 
> > > I was thinking on pushing the elf check a bit down instead,
> > > like the below.  However, having now tested this, I see that
> > > this doesn't work in most of the cores I have here (x86_64-linux).
> > > In most cases I see, the segment that would contain the program
> > > headers, as indicated by auxv info, isn't included in the
> > > core...
> > > 
> > > (objdump -h)
> > > Idx Name          Size      VMA               LMA               File off  Algn
> > >   :
> > >   6 load1         00000000  0000000000400000  0000000000000000  000008f8  2**0
> > >                   ALLOC, READONLY, CODE
> > >   :
> > > 
> 
> I'm somewhat amazed that the Linux kernel doesn't dump the auxv stuff.
> Without the auxv data, debugging core dumps of PIE executables will be
> impossible.
> 
> Perhaps the kernel does include the information in the does, but bfd
> doesn't have the necessary code to turn it into an .auxv section?

Nope, let me explain a bit better: the auxv data is there, but the
program headers aren't.

Idx Name          Size      VMA               LMA               File off  Algn
  0 note0         00000538  0000000000000000  0000000000000000  000003c0  2**0
                  CONTENTS, READONLY
  1 .reg/30270    000000d8  0000000000000000  0000000000000000  000004e0  2**2
                  CONTENTS
  2 .reg          000000d8  0000000000000000  0000000000000000  000004e0  2**2
                  CONTENTS
  3 .reg2/30270   00000200  0000000000000000  0000000000000000  000005d4  2**2
                  CONTENTS
  4 .reg2         00000200  0000000000000000  0000000000000000  000005d4  2**2
                  CONTENTS
  5 .auxv         00000110  0000000000000000  0000000000000000  000007e8  2**3
                  CONTENTS
  6 load1         00000000  0000000000400000  0000000000000000  000008f8  2**0
                  ^^^^^^^^
                  ALLOC, READONLY, CODE
                  ^^^^^^^^^^^^^^^^^^^^^
  7 load2         00001000  0000000000600000  0000000000000000  000008f8  2**0
                  CONTENTS, ALLOC, LOAD
  :

In this case, AT_PHDR points at 0x400040, but the data is just not there
in the core, because it is read-only data, and the kernel decided it
isn't worth to dump it (gdb's gcore does the same):

>cat /proc/18439/maps
00400000-00401000 r-xp 00000000 08:07 2819992                            /home/pedro/gdb/mainline/build/gdb/testsuite/gdb.base/annota1
                  ^^^^
00600000-00601000 rw-p 00000000 08:07 2819992                            /home/pedro/gdb/mainline/build/gdb/testsuite/gdb.base/annota1

Aleksandar, did you try the version of the patch I posted?

-- 
Pedro Alves