Fwd: Question regarding core dump debugging using gdb on armv4

Fwd: Question regarding core dump debugging using gdb on armv4

[Abhijit Ray Chaudhury]

Hi ,

I am trying to reduce core dump size on target running linux . The
processor is armv4 family. I tweak elf_core_dump function of linux
kernel 2.6.23.

I tweaked the kernel to dump only elf note, registers and stack
segments of the running process.

But gdb fails to load required shared object files and fails to give
the backtraces of the running process.

Could you please help me ascertain how gdb loads the required
libraries from the core dump. Which ELF section of the core contains
the information ?

Thanks in Advance,
-Abhijit

Re: Fwd: Question regarding core dump debugging using gdb on armv4

[Pedro Alves]

On 04/04/2013 04:30 AM, Abhijit Ray Chaudhury wrote:
> Hi ,
> 
> I am trying to reduce core dump size on target running linux . The
> processor is armv4 family. I tweak elf_core_dump function of linux
> kernel 2.6.23.
> 
> I tweaked the kernel to dump only elf note, registers and stack
> segments of the running process.
> 
> But gdb fails to load required shared object files and fails to give
> the backtraces of the running process.
> 
> Could you please help me ascertain how gdb loads the required
> libraries from the core dump. Which ELF section of the core contains
> the information ?

GDB reads the load map off of structures in the dynamic loader (which runs
in userspace).  The dynamic loader->debugger interface has a 'struct r_debug'
structure in memory that holds the list of loaded libraries.  You need to
preserve that and whatever it references in the core.

In dynamic executables you can find where r_debug is by consulting
the DT_DEBUG dyntag, found in the .dynamic section of the executable,
which in turn can be found in the PT_DYNAMIC program header,
which is found by scanning the OS auxiliary vector, which the kernel
has access to.  All this can be seen in action in gdb's solib-svr4.c.
Dumping all of libc's memory may work too..

-- 
Pedro Alves

Re: Fwd: Question regarding core dump debugging using gdb on armv4

[Abhijit Ray Chaudhury]

Pedro,

That is exactly what I wanted to do. I want get back traces of all the
running treads and the stack variables.

I would dump the NOTE PHDRS, which has NT_PRSTATTUS, NT_PRPSINFO,
NT_AUXV and a bunch of NT_PRSTATUS structures.
Then I need to decide which of the PHDRS ( which are of load type) ,
to be dumped.

From your answer it looked like I need lot of ELF parsing , so I think
I need to invoke user level program when core dump happens.

Do you know of any documents describing the shared object loading
process by gdb from core files ?

Thanks in advance,
-Abhijit

On Thu, Apr 4, 2013 at 2:49 PM, Pedro Alves <palves@redhat.com> wrote:
> On 04/04/2013 04:30 AM, Abhijit Ray Chaudhury wrote:
>> Hi ,
>>
>> I am trying to reduce core dump size on target running linux . The
>> processor is armv4 family. I tweak elf_core_dump function of linux
>> kernel 2.6.23.
>>
>> I tweaked the kernel to dump only elf note, registers and stack
>> segments of the running process.
>>
>> But gdb fails to load required shared object files and fails to give
>> the backtraces of the running process.
>>
>> Could you please help me ascertain how gdb loads the required
>> libraries from the core dump. Which ELF section of the core contains
>> the information ?
>
> GDB reads the load map off of structures in the dynamic loader (which runs
> in userspace).  The dynamic loader->debugger interface has a 'struct r_debug'
> structure in memory that holds the list of loaded libraries.  You need to
> preserve that and whatever it references in the core.
>
> In dynamic executables you can find where r_debug is by consulting
> the DT_DEBUG dyntag, found in the .dynamic section of the executable,
> which in turn can be found in the PT_DYNAMIC program header,
> which is found by scanning the OS auxiliary vector, which the kernel
> has access to.  All this can be seen in action in gdb's solib-svr4.c.
> Dumping all of libc's memory may work too..
>
> --
> Pedro Alves
>

Re: Fwd: Question regarding core dump debugging using gdb on armv4

[Abhijit Ray Chaudhury]

Pedro,

In solib-svr4.c function

static CORE_ADDR
elf_locate_base (void) {
...
/* Find DT_DEBUG.  */
  if (scan_dyntag (DT_DEBUG, exec_bfd, &dyn_ptr)
      || scan_dyntag_auxv (DT_DEBUG, &dyn_ptr))
    return dyn_ptr;

  /* This may be a static executable.  Look for the symbol
     conventionally named _r_debug, as a last resort.  */
  msymbol = lookup_minimal_symbol ("_r_debug", NULL, symfile_objfile);
  if (msymbol != NULL)
    return SYMBOL_VALUE_ADDRESS (msymbol);

Are you asking me going through this section of the code ?

Thanks,
-Abhijit

On Thu, Apr 4, 2013 at 2:49 PM, Pedro Alves <palves@redhat.com> wrote:
> On 04/04/2013 04:30 AM, Abhijit Ray Chaudhury wrote:
>> Hi ,
>>
>> I am trying to reduce core dump size on target running linux . The
>> processor is armv4 family. I tweak elf_core_dump function of linux
>> kernel 2.6.23.
>>
>> I tweaked the kernel to dump only elf note, registers and stack
>> segments of the running process.
>>
>> But gdb fails to load required shared object files and fails to give
>> the backtraces of the running process.
>>
>> Could you please help me ascertain how gdb loads the required
>> libraries from the core dump. Which ELF section of the core contains
>> the information ?
>
> GDB reads the load map off of structures in the dynamic loader (which runs
> in userspace).  The dynamic loader->debugger interface has a 'struct r_debug'
> structure in memory that holds the list of loaded libraries.  You need to
> preserve that and whatever it references in the core.
>
> In dynamic executables you can find where r_debug is by consulting
> the DT_DEBUG dyntag, found in the .dynamic section of the executable,
> which in turn can be found in the PT_DYNAMIC program header,
> which is found by scanning the OS auxiliary vector, which the kernel
> has access to.  All this can be seen in action in gdb's solib-svr4.c.
> Dumping all of libc's memory may work too..
>
> --
> Pedro Alves
>

Re: Fwd: Question regarding core dump debugging using gdb on armv4

[Pedro Alves]

On 04/08/2013 04:27 AM, Abhijit Ray Chaudhury wrote:

> Do you know of any documents describing the shared object loading
> process by gdb from core files ?

I don't.

-- 
Pedro Alves

Re: Fwd: Question regarding core dump debugging using gdb on armv4

[Pedro Alves]

On 04/08/2013 04:54 AM, Abhijit Ray Chaudhury wrote:
> Pedro,
> 
> In solib-svr4.c function
> 
> static CORE_ADDR
> elf_locate_base (void) {
> ...
> /* Find DT_DEBUG.  */
>   if (scan_dyntag (DT_DEBUG, exec_bfd, &dyn_ptr)
>       || scan_dyntag_auxv (DT_DEBUG, &dyn_ptr))
>     return dyn_ptr;
> 
>   /* This may be a static executable.  Look for the symbol
>      conventionally named _r_debug, as a last resort.  */
>   msymbol = lookup_minimal_symbol ("_r_debug", NULL, symfile_objfile);
>   if (msymbol != NULL)
>     return SYMBOL_VALUE_ADDRESS (msymbol);
> 
> Are you asking me going through this section of the code ?

Not sure what you mean, as I didn't ask anything, but
if you're asking if that's the GDB code that implements
what I explained, then yes.

-- 
Pedro Alves

Re: Fwd: Question regarding core dump debugging using gdb on armv4

[Pedro Alves]

On 04/08/2013 04:27 AM, Abhijit Ray Chaudhury wrote:
> From your answer it looked like I need lot of ELF parsing , so I think
> I need to invoke user level program when core dump happens.

No big elf parsing, just browsing through some
structures:

  OS auxiliary vector (which the kernel has access to)
   -> find PT_DYNAMIC program header
     -> find DT_DEBUG dyntag
        -> find r_debug
           -> follow r_debug.

But I definitely agree a user level program would be better than
hacking this in the kernel, which IMO wouldn't be likely accepted
upstream.

-- 
Pedro Alves