Re: gdb/dwarf-frame.c

Mark Kettenis
2003-05-09T19:36:47Z

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