From: Joern Rennecke <joernr@arc.com>
To: gdb@sourceware.org
Subject: Re: How do I replace DEPRECATED_TM_FILE?
Date: Fri, 13 Jul 2007 17:32:00 -0000 [thread overview]
Message-ID: <20070713173228.GC20939@elsdt-razorfish.arc.com> (raw)
In-Reply-To: <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').
prev parent reply other threads:[~2007-07-13 17:32 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-06-21 16:13 Joern Rennecke
2007-06-21 16:21 ` Daniel Jacobowitz
2007-06-21 17:33 ` Joern Rennecke
2007-06-21 17:44 ` Daniel Jacobowitz
2007-07-13 17:32 ` Joern Rennecke [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20070713173228.GC20939@elsdt-razorfish.arc.com \
--to=joernr@arc.com \
--cc=gdb@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox