[Bug corefiles/11579] New: RFE: backtrace core without any symfile_objfile

["jan dot kratochvil at redhat dot com" <sourceware-bugzilla at sourceware dot org>]

For backtracing a (for example x86_64) core file we need at least .eh_frame.
.eh_frame is read using bfd asection from the symbol files list (not only
symfile_objfile but also from shared libraries objfiles).

If you have longterm running program where the executable has been already
upgraded in the meantime you can no longer find .eh_frame for such running
program to backtrace it (for example in the case of its core dump).

For such upgraded=deleted running file you get (on GNU/Linux):
lrwxrwxrwx 1 root root 0 2010-05-06 10:07 /proc/29810/exe -> /tmp/sleep\ (deleted)
$ wc -c /proc/$p/exe
29152 /proc/29810/exe
$ wc -c /bin/sleep
29152 /bin/sleep

In this case the unlinked executable is still available for possible reading of
the executable exactly at the crash time from the /proc/sys/kernel/core_pattern
handler.  Still:
 * None of the upgraded .so libraries is available for file opening
   to read their .eh_frame.
 * For disk-stored core files we cannot read even the former /proc/PID/exe file.

Still .eh_frame can be made accessible from the standalone core file itself if
we start using: /proc/<pid>/coredump_filter
|= (bit 2) file-backed private memory | (bit 3) file-backed shared memory ;

How to read the information for backtracing normally looked up via section
headers (possibly not mapped into memory) instead from the program headers
(always mapped into memory) is described by Roland McGrath below:

Roland McGrath wrote:
> Jan Kratochvil wrote:
> Locally one cannot access upgraded .so files.

Right.  You can only get their text via the process's memory,
either while it's still alive or by including it in the core dump.
e.g. abrtd/etc could arrange coredump_filter settings to include
text and then have the coredump pipe processor extract .eh_frame
to save separately but then re-elide the text from the saved dump.

Of course, the kernel people could always be convinced to add
/proc/pid/mapped/ dir of pseudo-files that work like /proc/pid/exe.
Those are getting you the original contents of the file on disk (which
might now have 0 links but still be there), vs. reading process memory
where you might have COW'd touched text pages (with bkpts inserted or
whatever weirdness via ptrace or mprotect hackery).  OTOH, if binaries
on disk were touched in place by cp instead of overwritten by mv/install/rpm
then you should have the converse preference.

> This is a problem for local raw=numerical=symbol-less backtraces.

Right.  You need the CFI to get the basic backtrace.

> If we start using /proc/<pid>/coredump_filter
> |= (bit 2) file-backed private memory | (bit 3) file-backed shared memory
> we may possibly no longer need any reference to the files from filesystem.

Modulo touched memory issue (for better or worse), yes.

> But one still cannot find from the dumped core for each ELF binary
> .eh_frame - or is PHDR GNU_EH_FRAME (=.eh_frame_hdr) vaddr + memsiz safe
>             enough to assume it equals .eh_frame vaddr as it usually does?

It actually doesn't!  Even though indeed the normal layout has them
adjacent, an alignment padding word puts .eh_frame off by 4 in the first
x86-64 example I looked at.

You can follow PT_GNU_EH_FRAME to .eh_frame_hdr and decode its header to
find .eh_frame.  e.g. see libdw/dwarf_getcfi_elf.c.  That's the only way.

But .eh_frame_hdr is almost never going to be in the first page, and so not
in a core dump without full text.

>             How to find .eh_frame memsiz?

There is no way (except having shdrs).  You can just guess an upper bound.

> .got - DW_EH_PE_datarel relies on .got vaddr but .got vaddr is not in PHDR.

There is DT_PLTGOT in .dynamic, which is data touched at startup and so
always dumped.  PT_DYNAMIC points to .dynamic so you can search it.

### DT_PLTGOT is vaddr of .got.plt (not .got).  Unaware now how to get .got.

-- 
           Summary: RFE: backtrace core without any symfile_objfile
           Product: gdb
           Version: unknown
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P2
         Component: corefiles
        AssignedTo: unassigned at sourceware dot org
        ReportedBy: jan dot kratochvil at redhat dot com
                CC: gdb-prs at sourceware dot org


http://sourceware.org/bugzilla/show_bug.cgi?id=11579

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.