This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Dwarf-2 unwinding vs. manual prologue analysis
- From: Orjan Friberg <orjan dot friberg at axis dot com>
- To: gdb-patches at sources dot redhat dot com
- Date: Thu, 26 May 2005 16:59:05 +0200
- Subject: Dwarf-2 unwinding vs. manual prologue analysis
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?
For the record: I created a minimal prologue scanner for CRISv32 by using the
time-honoured method of gradually stripping away stuff from the CRISv10 version
until things stopped working. This is what I ended up with:
frame_unwind_unsigned_register (next_frame, SP_REGNUM, &this_base);
info->base = this_base;
info->prev_sp = this_base;
/* The PC is found in SRP (the actual register or located on the stack). */
info->saved_regs[PC_REGNUM] = info->saved_regs[SRP_REGNUM];
--
Orjan Friberg
Axis Communications