This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: Dwarf-2 unwinding vs. manual prologue analysis
- From: Daniel Jacobowitz <drow at false dot org>
- To: Orjan Friberg <orjan dot friberg at axis dot com>
- Cc: gdb-patches at sources dot redhat dot com
- Date: Thu, 26 May 2005 11:08:41 -0400
- Subject: Re: Dwarf-2 unwinding vs. manual prologue analysis
- References: <4295E439.7070104@axis.com>
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