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

Pedro Alves
2009-06-19T15:00:03Z

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