This is the mail archive of the gdb-patches@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: Dwarf-2 unwinding vs. manual prologue analysis


Please use gdb@ for questions; I expect most messages to gdb-patches to
be in need of review :-)

On Thu, May 26, 2005 at 04:59:05PM +0200, Orjan Friberg wrote:
> When adding the CRISv32 support, it seemed like a good idea to avoid having 
> to do manual prologue analysis to determine where registers are saved, 
> figuring out the return address etc.  For some reason I imagined I wouldn't 
> have to do this if I could use the Dwarf-2 frame sniffer (because all code 
> would have Dwarf-2 CFI).  I hooked in the Dwarf-2 frame sniffer and 
> everything ran fine, and it wasn't until just recently that I discovered 
> (to my horror) that the prologue scanner (meant for CRISv10 only; the ISAs 
> are not compatible) was not only called when debugging CRISv32, but simple 
> things like 'next' broke in various places in the testsuite when I didn't 
> do it.
> 
> I do feel a bit embarrased asking this, as one would think I'd know this 
> already.  Since I obviously don't, here we go:
> 
> Do I need to able to do manual prologue analysis when there's Dwarf-2 CFI 
> available?  If so, is there a set of minimum requirements for what that 
> analysis must be able figure out?

No.  If enabling the DWARF-2 CFI support causes things to break, then
you need to inspect your CFI; it is probably broken.  You need to do
prologue analysis if there's anything without CFI that you need to
handle, which there usually is - for instance PLT stubs.

-- 
Daniel Jacobowitz
CodeSourcery, LLC


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