gdb/dwarf-frame.c

[Roland McGrath <roland@redhat.com>]

(Hi Mark!  It's been too long since we hacked together.)
[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.

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?

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.


Thanks,
Roland