This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC] DWARF CFI: what to do with .eh_frame sections?


On Fri, May 09, 2003 at 05:58:26PM -0400, Andrew Cagney wrote:
> >On Fri, May 09, 2003 at 10:14:34PM +0200, Mark Kettenis wrote:
> >
> >>It's clear that we want to support unwinding using info in .eh_frame
> >>sections in addition to .debug_frame sections.  I'm inclined to make
> >>to make dwarf-frame.c provide two frame unwinders: one that uses
> >>.debug_frame info, and one that uses .eh_frame info.  That way it will
> >>be possible to let the target determine if .dwarf_frame will be
> >>preferred over .eh_frame or not.
> >>
> >>Thoughts?
> >
> >
> >That seems reasonable.  I'd probably create a single function to
> >register both unwinders, and call it from each target, though;
> >since there's no reason I can think of to prefer one over the other
> >modula unknown GDB bugs.
> 
> Think of it as a two tiered effect, you know with ... (sorry).
> 
> If I understand the cfi stuff correctly, it can be broken down into:
> 
> - the cfi engine
> - the cfi byte stream source
> 
> (kind of like dwarf2expr)  The latter can be debug info, .eh_frame, or 
> even (as long a go proposed) hand written code.

Ah yes, I'd forgotten about this.  It's becoming less important but it
would still be useful.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]