Adding a missing NT_FILES note to a core file so gdb can load solibs for it

Adding a missing NT_FILES note to a core file so gdb can load solibs for it

[Bogdan Harjoc]

I received some mips core files from an openwrt machine where all
.so's are sstripped: all the sections at the end are trimmed except
those strictly needed to run programs. All standard openwrt images are
built like this.

Reading the core files with readelf doesn't show any NT_FILES note,
and from stepping through the code, it seems this causes
solib_svr4_r_map() to fail, and "info sharedlibrary" shows nothing of
course.

I'm about to add that missing section back to the core file hoping it
will fix the automating loading of solibs. Google-coredumper [1] looks
like a good start for this, and cores are ELF files anyway. The load
addresses will be taken from the mapping that "info proc mappings"
outputs, it seems to be the same information.

[1] https://code.google.com/p/google-coredumper

So I'd like to ask whether this has any chance of working.

Thanks,
Bogdan

Re: Adding a missing NT_FILES note to a core file so gdb can load solibs for it

[Jan Kratochvil]

On Mon, 25 Jan 2016 15:06:05 +0100, Bogdan Harjoc wrote:
> So I'd like to ask whether this has any chance of working.

No.  GDB does not support NT_FILE reading.  GDB follows DT_DEBUG:
	readelf -d execbinary|grep -w DEBUG

Besides that it would not be completely correct, depending on the point of
view.  mmap()ped shared library will be present in NT_FILE but GDB will not
shows it as it was not dlopen()ed (either by a call or via DT_NEEDED).

When GDB cannot read shared libraries it usually means your executable does
not exactly match the one that was core dumped.  To make them matching one
should match build-id from the core file with that of the executable:
	eu-unstrip -n --core=corefile
	readelf -n execbinary|grep -A1 NT_GNU_BUILD_ID
IIRC ld-linux.so also needs to match, I cannot remember why now.


Jan

Re: Adding a missing NT_FILES note to a core file so gdb can load solibs for it

[Bogdan Harjoc]

Thanks, a comment in elf_locate_base() confirms NT_FILES wouldn't work:

/* Look for DT_MIPS_RLD_MAP first.  MIPS executables use this instead
of DT_DEBUG [...] */

Solib loading apparently fails here:

#0 read_memory_typed_address (info->debug_base + lmo->r_map_offset)
the map
#1 solib_svr4_r_map

because read_memory...() reads 0x0 from info->debug_base + lmo->r_map_offset.

What I can't figure out is where the rld map should be in the core file.

Thanks.

On Mon, Jan 25, 2016 at 4:22 PM, Jan Kratochvil
<jan.kratochvil@redhat.com> wrote:
> On Mon, 25 Jan 2016 15:06:05 +0100, Bogdan Harjoc wrote:
>> So I'd like to ask whether this has any chance of working.
>
> No.  GDB does not support NT_FILE reading.  GDB follows DT_DEBUG:
>         readelf -d execbinary|grep -w DEBUG
>
> Besides that it would not be completely correct, depending on the point of
> view.  mmap()ped shared library will be present in NT_FILE but GDB will not
> shows it as it was not dlopen()ed (either by a call or via DT_NEEDED).
>
> When GDB cannot read shared libraries it usually means your executable does
> not exactly match the one that was core dumped.  To make them matching one
> should match build-id from the core file with that of the executable:
>         eu-unstrip -n --core=corefile
>         readelf -n execbinary|grep -A1 NT_GNU_BUILD_ID
> IIRC ld-linux.so also needs to match, I cannot remember why now.
>
>
> Jan

Re: Adding a missing NT_FILES note to a core file so gdb can load solibs for it

[Jan Kratochvil]

On Mon, 25 Jan 2016 16:56:53 +0100, Bogdan Harjoc wrote:
> because read_memory...() reads 0x0 from info->debug_base + lmo->r_map_offset.
> 
> What I can't figure out is where the rld map should be in the core file.

This is usually because I said that most commonly the executable does not
match the one from the core file.  And therefore that computed address is
bogus and statistically memory contains most probably zeroes which is what you
see, the zero.


Jan