* [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).