Dwarf-2 unwinding vs. manual prologue analysis

Orjan Friberg
2005-05-26T14:59:14Z

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