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

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

[Craig Hackney]

	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

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

[Richard Earnshaw]

Adding support for the modal registers (irq/fiq etc) is one of the things 
I'm going to try to take into account while I'm fixing the current mess 
with accessing the regcache.

R.

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

[Andrew Cagney]

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

A single GDB executable is capable of handling multiple architectures.

I can think of several ways of extending arm-tdep.c to support the extra 
registers.  Off hand:

	- add a command to ``enable'' the registers

	- have that command force an architecture change by calling 
gdbarch_update_p().

	- this will force a call to arm_gdbarch_init()

	- that function is then free to re-layout the register cache the way you 
want.

Andrew

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

[Craig Hackney]

	Thats Great News! I have already hacked a few files to support
	this for our A7 target, let me know if you are interested in
	seeing the patch files.


-----Original Message-----
From: Richard Earnshaw [mailto:rearnsha@arm.com]
Sent: Friday, May 10, 2002 10:07 AM
To: Craig Hackney
Cc: 'Andrew Cagney'; 'gdb@sources.redhat.com'; Richard.Earnshaw@arm.com
Subject: Re: Displaying more than 16 registers with GDB for ARM targets 


Adding support for the modal registers (irq/fiq etc) is one of the things 
I'm going to try to take into account while I'm fixing the current mess 
with accessing the regcache.

R.

Displaying more than 16 registers with GDB for ARM targets

[Craig Hackney]

	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.

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

[Andrew Cagney]

> 	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