This is the mail archive of the
mailing list for the GDB project.
RE: Displaying more than 16 registers with GDB for ARM targets
- From: Craig Hackney <craig at triscend dot com>
- To: 'Andrew Cagney' <ac131313 at cygnus dot com>, Craig Hackney <craig at triscend dot com>
- Cc: "'gdb at sources dot redhat dot com'" <gdb at sources dot redhat dot com>
- Date: Fri, 10 May 2002 10:02:29 -0700
- Subject: RE: Displaying more than 16 registers with GDB for ARM targets
My main issue is that I didn't want to change the
current ARM arch of GDB, rather I wanted to keep as much
of it the same as I could but allow it to be extended to
handle the the extra registers I have.
So it sounds like, I have to hack into the current ARM arch
to make it support my extra registers, this would mean that
they would be displayed for all ARM targets. Even if the
target does not support them.
Create a completely new architecture that is based 99% on the
ARM, but has my extra register support.
Am I missing something, or does that about sum it up?
From: Andrew Cagney [mailto:email@example.com]
Sent: Thursday, May 09, 2002 8:55 PM
To: Craig Hackney
Subject: Re: Displaying more than 16 registers with GDB for ARM targets
> 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().
> 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.
As a rule of thumb[er groan] with GDB, adding #define's to headers
suggests something going wrong.
Have a closer look at arm_gdbarch_init(). You can change each of these
parameters, as required from that function without adding extra #defines.
> 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
> Since GDB only displays registers that it has names for, and
> my extra registers have no names, they are not displayed by
> I have expanded on GDBs 'set disassembly-flavor' command which
> allows the selection of different names for the standard ARM
> registers R0-R15.
I don't think this is the way to do it. Per above, you simply want to
modify arm_gdbarch_init() so that it correctly describes your new
Separate to this, you may want to consider mechanisms for having the
target (via gdbarch_update_p() et.al.) notifing core gdb of the current
architecture (for instance your new architecture).