This is the mail archive of the gdb@sourceware.org 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] |
On Thu, Jun 21, 2007 at 12:21:52PM -0400, Daniel Jacobowitz wrote: > Why are the register numbers different (and which register numbers)? > That determines the answer to your question. If it's the dwarf2 > mapping, for instance, you'd put overrides in an OS/ABI sniffer in the > Linux tdep file. I did some more digging, and found that apparently the dwarf register numbers start out the same, but they are translated with dwarf_reg_to_regno functions to be different. As far as I can tell, the problem stems from gdbserver coupling the target communication directly with the register cache. The register numbers that arc-linux uses are different than the hardware and the dwarf register numbers. Moreover, some registers are not accessible, and some values appear as registers that actually give a view of some of the data that is not direcly accessible: ret, orig_r8 and stop_pc. Two of the registers that are not directly accessible are ilink1 and ilink2, which contain the return from interrupt address for interrupts of level 1 and level 2, respectively. Linux saves only the return address for the previous frame, e.g. for a level 1 interrupt, it will save ilink1 in ret, and set orig_r8 to -1 to indicate that that is what is in ret. I suppose it could make sense to try to make the linux target look more like the hardware to the gdb user, by translating these values the best we can, but I don't see how this can be done with gdbserver; linux-low.c seems to assume that the linux register set and numbering must be exactly what the gdb user sees. I must admit I don't think I understand gdbserver very well yet; is there any overview of the gdbserver internals like gdbint.texinfo for the rest of gdb? Although it took me quite a while to read through that document, it left me with a better understanding (I hope) of how things are supposed to fit together in gdb (although I had to resort to grep to confirm that (and findout why) the _initialize_* functions are 'magic').
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |