Re: gdb/dwarf-frame.c

[Mark Kettenis <kettenis at chello dot nl>]

   Date: Fri, 9 May 2003 02:45:29 -0700
   From: Roland McGrath <roland@redhat.com>

   (Hi Mark!  It's been too long since we hacked together.)

(Hi Roland!  I've drifted away a bit from glibc and the Hurd :-(.)

   [Please note that I am not on the mailing list, so keep me CC'd directly.]

   I have been looking at the kettenis_i386newframe-20030419-branch gdb code.
   I've been told that the new dwarf-frame.c replaces the dwarf2cfi.c code
   that's on mainline.  I don't know the guts of either or of DWARF2 itself
   well enough to compare them.

dwarf2cfi.c currently has more complete support for DWARF CFI, but
suffers from some design flaws, which probably makes it unusable for
debugging any serious project.

   What I have noticed is that dwarf-frame.c does not seem to handle the
   .eh_frame section, only the .debug_frame section.  The dwarf2cfi.c code
   looks at both.  As well as looking for the section, it needs to grok the
   "augmentation" values and different encodings used in .eh_frame, and I
   don't see any of that handled in the new code.  Is this an intentional
   omission and if so what is the rationale?

Daniel is right here.  I'm busy writting the support for .eh_frame
sections.  I just left them out since they complicate matters quite a
bit.

   I think grokking .eh_frame sections in the absence of .debug_frame is a
   nice thing in general--it might give you at least some more helpful
   backtraces than otherwise when dealing with binaries without debugging
   info.  But the particular reason it is of concern to me is that it's needed
   for unwinding PC values within the special kernel entrypoint page now being
   used in Linux on x86.  glibc now uses this entrypoint code for every system
   call, and so any thread blocked in a system call (which most threads one
   looks at are when one starts looking) will have its PC inside this code and
   need to be able to unwind that frame-pointer-less leaf frame to produce a
   useful backtrace.  This is magic kernel code for which there is never going
   to be debugging information, but for which we do have .eh_frame information
   we can get at.  I am setting about attacking how we get at it in all the
   relevant cases, but I had been working from the assumption that upon
   locating some information in .eh_frame form (including "zR" augmentation
   and pcrel pointer encoding) it would plug easily into the DWARF2 unwinding
   machinery.  If that's not so, it throws a monkey wrench into my plans.

It certainly is my intention to make it possible, although It's not
clear how things should be glued together.  I've seen your kernel
patches and it seems as if there are two possibilities:

1. Reading the complete DSO from target memory, and somehow turning it
   in a bfd.  That would make it possible to use the existing symbol
   reading machinere to read symbols and .eh_frame info.

2. Write a symbol reader that uses the run-tume dynamic linker (struct
   r_debug, struct link_map) to locate the dynamic section of the
   shared object, and uses it to read the relevant loaded sections of
   the DSO from the target and interpret those bits.

If I'm not mistaken, the latter would also allow us to construct a
minimal symbol table for DSO's even if the we don't have access to an
on-disk file.  We'll probably need some serious hacking on GDB's
shared library support to make this all possible.

Mark