RE: Displaying more than 16 registers with GDB for ARM targets

[Craig Hackney <craig@triscend.com>]

	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.

	Or..

	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?



-----Original Message-----
From: Andrew Cagney [mailto:ac131313@cygnus.com]
Sent: Thursday, May 09, 2002 8:55 PM
To: Craig Hackney
Cc: 'gdb@sources.redhat.com'
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().

> 	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.


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
> 	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 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 
architecture.

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).

enjoy,
Andrew