* [RFC] DWARF CFI: what to do with .eh_frame sections?
@ 2003-05-09 20:14 Mark Kettenis
2003-05-09 20:20 ` Daniel Jacobowitz
0 siblings, 1 reply; 5+ messages in thread
From: Mark Kettenis @ 2003-05-09 20:14 UTC (permalink / raw)
To: gdb
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?
Mark
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [RFC] DWARF CFI: what to do with .eh_frame sections?
2003-05-09 20:14 [RFC] DWARF CFI: what to do with .eh_frame sections? Mark Kettenis
@ 2003-05-09 20:20 ` Daniel Jacobowitz
2003-05-09 21:58 ` Andrew Cagney
0 siblings, 1 reply; 5+ messages in thread
From: Daniel Jacobowitz @ 2003-05-09 20:20 UTC (permalink / raw)
To: Mark Kettenis; +Cc: gdb
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.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [RFC] DWARF CFI: what to do with .eh_frame sections?
2003-05-09 20:20 ` Daniel Jacobowitz
@ 2003-05-09 21:58 ` Andrew Cagney
2003-05-09 22:27 ` Daniel Jacobowitz
0 siblings, 1 reply; 5+ messages in thread
From: Andrew Cagney @ 2003-05-09 21:58 UTC (permalink / raw)
To: Daniel Jacobowitz; +Cc: Mark Kettenis, gdb
> 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.
Andrew
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [RFC] DWARF CFI: what to do with .eh_frame sections?
2003-05-09 21:58 ` Andrew Cagney
@ 2003-05-09 22:27 ` Daniel Jacobowitz
2003-05-09 23:59 ` Andrew Cagney
0 siblings, 1 reply; 5+ messages in thread
From: Daniel Jacobowitz @ 2003-05-09 22:27 UTC (permalink / raw)
To: Andrew Cagney; +Cc: Mark Kettenis, gdb
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [RFC] DWARF CFI: what to do with .eh_frame sections?
2003-05-09 22:27 ` Daniel Jacobowitz
@ 2003-05-09 23:59 ` Andrew Cagney
0 siblings, 0 replies; 5+ messages in thread
From: Andrew Cagney @ 2003-05-09 23:59 UTC (permalink / raw)
To: Daniel Jacobowitz; +Cc: Mark Kettenis, gdb
> 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
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2003-05-09 23:59 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-05-09 20:14 [RFC] DWARF CFI: what to do with .eh_frame sections? Mark Kettenis
2003-05-09 20:20 ` Daniel Jacobowitz
2003-05-09 21:58 ` Andrew Cagney
2003-05-09 22:27 ` Daniel Jacobowitz
2003-05-09 23:59 ` Andrew Cagney
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).