This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: How do I replace DEPRECATED_TM_FILE?
- From: Joern Rennecke <joernr at arc dot com>
- To: gdb at sourceware dot org
- Date: Fri, 13 Jul 2007 18:32:28 +0100
- Subject: Re: How do I replace DEPRECATED_TM_FILE?
- References: <20070621161305.GD8169@elsdt-razorfish.arc.com> <20070621162152.GA18158@caradoc.them.org>
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').