From: Orjan Friberg <orjan.friberg@axis.com>
To: gdb@sources.redhat.com
Subject: Register fudging (CRISv32)
Date: Fri, 03 Sep 2004 12:37:00 -0000 [thread overview]
Message-ID: <4138656F.9020001@axis.com> (raw)
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
next reply other threads:[~2004-09-03 12:37 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-09-03 12:37 Orjan Friberg [this message]
2004-09-03 13:47 ` Daniel Jacobowitz
2004-09-03 14:31 ` Orjan Friberg
2004-09-03 16:03 ` Daniel Jacobowitz
2004-09-06 12:00 ` Orjan Friberg
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=4138656F.9020001@axis.com \
--to=orjan.friberg@axis.com \
--cc=gdb@sources.redhat.com \
/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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).