On Fri, 09 Oct 2009 11:18:57 +0200, Jan Kratochvil wrote:
The problem is that GDB needs for proper numeric backtrace the
section stored in the binary file itself.
Such .eh_frame is currently not even dumped to the core file and it is no
longer present anywhere on the system after the program core dumps/quits.
Asking for .eh_frame external untrusted source (such as the retrace server)
would be equivalent to disclosing the full core file content (as it can ask
through specially crafted .eh_frame for any interesting part of memory).
kernel elf_core_dump() (possible with vma_dump_size()) could possibly dump the
.eh_frame section into the core file - it would need some segment to point at
it, currently no such segment exists. PT_GNU_EH_FRAME covers .eh_frame_hdr
but not .eh_frame itself. .eh_frame_hdr dumped without .eh_frame is
insufficient, it only points to it. glibc is interested only in
PT_GNU_EH_FRAME's p_vaddr so either (a) PT_GNU_EH_FRAME's p_memsz could be
extended to cover also .eh_frame or (b) New PT_GNU_EH_FRAME2 could be created
(current PT_GNU_EH_FRAME should have been called PT_GNU_EH_FRAME_HDR.)
Still I expect in the future no on-disk core file should be generated for the
ABRT purposes as when the program crashes and `/proc/sys/kernel/core_pattern'
of ABRT is run so ABRT could extract only the required information from the
in-memory image. In such case the .eh_frame section would be still available
from the on-disk file (despite the file can be already deleted).
As currently ABRT still generates the core file on disk and uses external GDB
even for the numerical backtrace temporarily proposing to: (1) set
/proc/*/coredump_filter |= 0x08 to dump all the `file-backed shared memory'
including `.eh_frame'. (2) Improve GDB to be able to find .eh_frame sections
just from a core file, without needing the build-id matching external binary
files to exist.