From: Craig Hackney <craig@triscend.com>
To: "'gdb@sources.redhat.com'" <gdb@sources.redhat.com>
Subject: Displaying more than 16 registers with GDB for ARM targets
Date: Wed, 01 May 2002 19:57:00 -0000 [thread overview]
Message-ID: <2407239113CD914CBA855A47698F01B06222F8@SUGAH2.triscend.com> (raw)
Hi,
I'm working with a remote ARM target that is capable of sending
CPU registers for all CPU modes (FIQ, IRQ, etc...) 37 registers
in total. However GDB only displays a max of 16 registers,
R0-R15 plus a few floating point ones.
I have been looking at a way to allow GDB to display my extra
registers without having to change the ARM architecture of GDB
for my specific target. And I'd like to share my findings to see
if this is the best way of doing it.
There are two main problems which I have outlined below.
PROBLEM 1:
GDB uses a #define called NUM_REGS to determine how many
registers a target has, this #define uses gdbarch_num_regs()
to return the number of registers for a specific target.
For ARM targets, the number of registers is set by calling
set_gdbarch_num_regs() in arm-tdep.c the value passed is
NUM_GREGS + NUM_FREGS + NUM_SREGS which totals about 26.
NUM_REGS is used to allocate memory for the register_valid,
and registers variables in regcache.c. Since my target returns
37 registers, there is not enough space to store them all
using supply_register().
SOLUTION:
Add a #define to arm-tdep.h called MAX_ARM_REGS, this #define
is the max number of registers for all ARM targets, currently
I'm using a value of 48, which is is enough for the currently
supported ARM registers, plus the extra ones I need.
This #define is then used in arm-tdep.c to set the number
of registers for the ARM target with the call to
set_gdbarch_num_regs(). Now when space is allocated for the
register_valid and registers variables, there is enough
space for my extra registers so I can call supply_register()
with out a core dump.
PROBLEM 2:
There is no way to dynamically change the register names
based on a target selection. For example, lets say I create
a remote target interface based on remote.c, when I read the
target registers by issuing the remote 'g' command I get
all 37 registers back from the target and inform GDB by calling
supply_register().
Since GDB only displays registers that it has names for, and
my extra registers have no names, they are not displayed by
GDB.
SOLUTION:
I have expanded on GDBs 'set disassembly-flavor' command which
allows the selection of different names for the standard ARM
registers R0-R15.
I updated the regnames structure in arm-dis.c so that
it can hold upto 48 (the same as MAX_ARM_REGS) register
names instead of 16. This allows me to add my extra register
names. I also added an entry to the arm_regname structure that
contains the number of registers for each flavor.
The get_arm_regnames() function in arm-dis.c now returns
the number of registers from the new entry in the
arm_regname structure instead of a hard coded 16.
I updated the set_disassembly_flavor() function in arm-tdep.c
so that it uses the value returned from the get_arm_regnames()
function to set the correct number of register names. Since
the register names are copied to the arm_register_name_strings
variable in arm-tdep.c I also increased the array size of this
variable to MAX_ARM_REGS again to prevent a core dump.
With all of these changes I am able to execute the
'set disassembly-flavor' command and have GDB display all
of my registers.
Last but not least, I wanted to be able to change the register
names (disassembly-flavor) from within my own version of
remote.c. So I added a function called set_register_name() to
arm-tdep.c, now I can call this function to setup the register
names that I want to use from within my remote target back end,
since I do this when the target is 'opened', the register names
only change when my target is used.
next reply other threads:[~2002-05-02 2:57 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-05-01 19:57 Craig Hackney [this message]
2002-05-09 20:55 ` Andrew Cagney
2002-05-10 10:02 Craig Hackney
2002-05-10 10:07 ` Richard Earnshaw
2002-05-12 20:43 ` Andrew Cagney
2002-05-10 10:15 Craig Hackney
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=2407239113CD914CBA855A47698F01B06222F8@SUGAH2.triscend.com \
--to=craig@triscend.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