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]

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


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