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

[Andrew Cagney <ac131313@redhat.com>]

> 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.

It could also point into the .eh_frame stuff that describes the wacky 
(funky?) Linux kernel syscall area (well in theory at least, right now 
it's hard to figure out what there is, and how it is accessed :-( ).

Andrew