This is the mail archive of the gdb@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]

Register fudging (CRISv32)


My upcoming CRISv32 port (remote target, Linux based) is starting to look pretty good(*) but I'm left with a nagging feeling that the register fudging I'm doing isn't necessarily done where it should be and/or the right way. Right now it's being done in three different places (this relating to debugging user-mode programs):

(1) in the kernel
(2) in the Gdbserver
(3) in GDB

Basically, what I would like to hear is people's opinions on how various kinds of register fudging should be done.

On to the details:

* The first fudging is the equivalent to DECR_PC_AFTER_BREAK, though it's not using that mechanism in GDB; instead it's being done in the kernel. On one hand I feel more comfortable doing it in the kernel where I know exactly what happens; on the other hand the decrementation needs to be duplicated in, for example, a classic kernel gdb stub. Should I be using DECR_PC_AFTER_BREAK in GDB instead? Or the implementation in the Gdbserver?

* Another fudging that takes place is the filling in of a pseudo-PC register (there is no actual PC register, so it's not present in struct pt_regs). This is being done in the Gdbserver. In addition, in case we stopped in a delay slot, I *may* need to look at the code to determine what the PC should be set to (meaning I can't rely on register contents alone). I've found 3 cases where this needs to be done:

  (1) In case of a stop (break, h/w watchpoint, receiving a signal etc)
  (2) When unwinding a sigtramp frame
  (3) When loading a core dump (supply_gregset)

As of now, delay-slot-adjustment of the PC is only being done for the first case (normal stop), and it's also done in the Gdbserver. The other two cases don't handle being stopped in a delay slot yet, though I have a hunch this could be done in GDB.

* In addition to this, I need to set the h/w single-step PC to 0 in the kernel at various times, but I've seen other architectures doing that and I feel pretty confident that is the right way to do it.

Thanks for any insights.


(*) the gdb.base testsuite results in about 6050 PASS and around 20 FAIL (the relatively new sigbpt.exp, siginfo.exp, signull.exp, and sigstep.exp are all PASS - yay!)


--
Orjan Friberg
Axis Communications



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