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]

Re: How do I replace DEPRECATED_TM_FILE?


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]