Re: gdb/dwarf-frame.c

[Elena Zannoni <ezannoni@redhat.com>]

Daniel Jacobowitz writes:
 > On Fri, May 09, 2003 at 02:45:29AM -0700, Roland McGrath wrote:
 > > (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?
 > 
 > My understanding from Mark's earlier post is that it is an intentional
 > but probably temporary omission - since dwarf-frame is only a week or
 > two old at this point.
 > 
 > > 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.
 > 
 > Should any work even be necessary?  My understanding was that the
 > kernel code would show up in the shared library list.  Oh, I guess it
 > is - we usually locate .eh_frame via BFD, which means section headers
 > and an on-disk file.  I see.
 > 

Which reminds me that we should probably have the NPTL thread support
patches integrated in gdb as well, since we are at this (and I have
your attention). Can somebody (Daniel, Mark?) take a look at the
patches? I can guarentee that they work, since they were shipped with
RHL9's gdb.

elena


 > -- 
 > Daniel Jacobowitz
 > MontaVista Software                         Debian GNU/Linux Developer