Adding Registers

Adding Registers

[David Mc Kenna]

Hi,

Is it possible to add extra registers to gdb that link to a memory address,
eg R0 links to 0x00h ? If so how can I add another register, eg R20 to 0x016h,
to be displayed in the register window of Insight?

Thanks,
Dave Mc Kenna


--
http://www.iol.ie

Re: Adding Registers

[Duane Ellis]

dave> Is it possible to add extra registers to gdb that link to a memory address,
      eg R0 links to 0x00h ?

Not directly with out of the box prebuilt stuff. but if you want to
modify/tweak GDB sources to do something like this.... you can do it.

I know you can do that... I've done things like that on a few custom
ports I've done. :->

Basically you need to look at the CPU definition file for the machine
you want want to use.

For instance: Our custom cpu has 3 banks of 16 registers, 32bits each,
plus a few spares. We actually tell GDB there are 4 banks, plus the
extra ones. The "Current bank" and bank 0,1 and 2. The current bank
ends up being a ghost of what ever happens to be the current bank.

Example:

In the various "tm-CPUNAME.h" files (tm-arm.h, tm-m68k.h, etc) Look
for 'NUM_REGS', increase this number.  There are a number of other
macros that need tweaking.

Things like: "REGISTER_BYTES" and "REGISTER_BYTE()" macros,
and the register names to name a few.

In some of the target machine descriptions you'll notice that they
talk about "phony" registers, that's basically what you are doing.

You'll want to look at the functions (really macros) in target.h

       target_fetch_registers()
       target_store_registers()

and work through how they are called.

Basically, when GDB needs a register value, it will
call the function:

	   target_fetch_register( MY_FUNKY_REGISTER )

You'll need to modify whatever that eventually resolves to in the
target machine code (typically the "CPUNAME-tdep.c" file) so that it
does something like this:

void
my_target_fetch_register( int id )
{
	if( (id >= MY_FIRST_FUNKY_REGISTER) && 
	    (id <= MY_LAST_FUNKY_REGISTER) ){
		do_that_special_thing(id);
	} else {
	        call_existing_code(id);
	}
}

There are caviats to this:

GDB will seemingly periodically randomly call and ask for registers
when you least expect it, you quitely must just supply something or
have GDB go wacky on you. [Certian registers are only readable in
certian modes (ie: supervisor or user), or if the hardware is
configured a certian way.]

Another problem is if you are using a graphical front end, like
insight the display register window can get really huge and darn right
ugly.

In the specific example you give, if you modify memory via other means
(ie: Peek/Poke bytes some how) the values in the static register
display will be out of sync with what is in memory.

Doing things like this can be viewed like this: 

      You give a somebody a knife.
      You remind them they can cut themself. 
      They walk away, only to return bleeding and confused. 
      Do you really want to give them the knife?
      Is the knife really that important?

I find that many times you must give them the knife. You just wish
some of the others never found the knife. There are those people who
just don't, won't, or refuse to understand the danger of the knife.

-Duane.

Re: Adding Registers

[Keith Seitz]

On Tue, 12 Feb 2002, Duane Ellis wrote:

[snip excellent description of register handling in gdb]

One small thing to add (which is pretty obvious, but just to make sure):
Insight gets its register list from gdb. Anything in REGISTER_NAMES will
show up in Insight's register window.

> Doing things like this can be viewed like this:
>
>       You give a somebody a knife.
>       You remind them they can cut themself.
>       They walk away, only to return bleeding and confused.
>       Do you really want to give them the knife?
>       Is the knife really that important?

Very good! Alas, as you, too, have discovered a saying that I've often
used discussing some aspects of gdb/Insight: we cannot prevent stupid
people from doing stupid things. If you give someone a knife, he should
know to use it properly. Misusing it can lead to all sorts of bad things.

Keith

Re: Adding Registers

[Andrew Cagney]

Just FYI,
> On Tue, 12 Feb 2002, Duane Ellis wrote:
> 
> [snip excellent description of register handling in gdb]


Just BTW, gdb's internals have changed.

> One small thing to add (which is pretty obvious, but just to make sure):
> Insight gets its register list from gdb. Anything in REGISTER_NAMES will
> show up in Insight's register window.
>> Doing things like this can be viewed like this:

You may want to look at:

http://sources.redhat.com/gdb/ari/

If a macro/method is listed on there then you'll likely run into problems.

enjoy,
Andrew

Re: Adding Registers

[David Mc Kenna]

Thanks for the help.

Just one or two more questions.

I have modified tm-arm.h from

#define NUM_GREGS	16	/* Number of general purpose registers.  */

to

#define NUM_GREGS	18	/* Number of general purpose registers.  */

This increases the number of registers that is seen by GDB/Inishgt by 2.

I have modified arm-tdep.c from

"fps", "cpsr"}; 		/* 24 25 26 27     */ 

to

"fps", "cpsr", "r13" , "r14" }; 		/* 24 25 26 27    
 */  /*Modified by David
McKenna */

I have recompilied Insight/GDB with no problems and the new registers appear

in the Register window.

I have tried looking for the function target_fetch/store_registers() but I am

unable to locate it in any C file. I am assuming that this is where you define

what memory location you want the registers to look at. 

If possible could you point me in the right direction,

Thanks,
Dave Mc Kenna
--
http://www.iol.ie

Re: Adding Registers

[Duane Ellis]

david> I have tried looking for the function
       target_fetch/store_registers() but I am unable to locate it in
       any C file. I am assuming that this is where you define

Look for these two macros in target.h

#define	target_fetch_registers(regno)	\
     (*current_target.to_fetch_registers) (regno)
#define	target_store_registers(regs)	\
     (*current_target.to_store_registers) (regs)

You need to determine what those function pointers resolve to for your
specific target. Then modify the "pointed to" functions accordingly.

-Duane.

Re: Adding Registers

[Andrew Cagney]

Just FYI,

The register names in the Arm target are no longer hardwired.  Instead 
functions are used to map between a name and their internal number. 
Have a look around any of the newer targets for how this is done.  Grep 
for gdbarch_init.

Andrew

> Thanks for the help.
> 
> Just one or two more questions.
> 
> I have modified tm-arm.h from
> 
> #define NUM_GREGS	16	/* Number of general purpose registers.  */
> 
> to
> 
> #define NUM_GREGS	18	/* Number of general purpose registers.  */
> 
> This increases the number of registers that is seen by GDB/Inishgt by 2.
> 
> I have modified arm-tdep.c from
> 
> "fps", "cpsr"}; 		/* 24 25 26 27     */ 
> 
> to
> 
> "fps", "cpsr", "r13" , "r14" }; 		/* 24 25 26 27    
>  */  /*Modified by David
> McKenna */
> 
> 

Re: Adding Registers

[David Mc Kenna]

Thanks for the help.

A few more questions. Andrew refers to the internal number of each register.
I am dealing with a memory mapped register and as such it has no number, how
is this dealt with in the functions.

Also I have not found were the registers are written, I have gotten as far as


void
gdbarch_register_write (struct gdbarch *gdbarch, int regnum, char *buf)
{
  if (gdbarch->register_write == 0)
    internal_error (__FILE__, __LINE__,
                    "gdbarch: gdbarch_register_write invalid");
  if (gdbarch_debug >= 2)
    fprintf_unfiltered (gdb_stdlog, "gdbarch_register_write called\n");
  gdbarch->register_write (gdbarch, regnum, buf);
}

from gdbarch.c .

Were do I go from here?

Any help is greatly appreciated,
Dave Mc Kenna
--
http://www.iol.ie

Re: Adding Registers

[Duane Ellis]

david> Andrew refers to the internal number of each register.  I am
       dealing with a memory mapped register and as such it has no
       number, how is this dealt with in the functions.

You are thinking like "r0" "r1" and such.

What number would you then apply to the PC, or the STACK pointer?

Numbers are some what arbitrary. Think of it as "register id" ID
numbers 0..15 mean registers 0..15, id 16 is PC, 17 is stack, 18 is
flags register, 19 is this, and 20 is that, and 21 is _other_

david> I have gotten as far as

Good, next step is to fire up the debugger, and set a break point at
that specific function. Run GDB, and use the GDB commands to modify or
change a register.

BANG - you hit the break point, and you step into the function keep
stepping till you find the function you need tomodify. Exit GDB, and
hack away.

This method sure beats digging through source... and un-winding macros.

-Duane.

Re: Adding Registers

[Andrew Cagney]

> david> Andrew refers to the internal number of each register.  I am
>        dealing with a memory mapped register and as such it has no
>        number, how is this dealt with in the functions.
> 
> You are thinking like "r0" "r1" and such.
> 
> What number would you then apply to the PC, or the STACK pointer?
> 
> Numbers are some what arbitrary. Think of it as "register id" ID
> numbers 0..15 mean registers 0..15, id 16 is PC, 17 is stack, 18 is
> flags register, 19 is this, and 20 is that, and 21 is _other_
> 
> david> I have gotten as far as
> 
> Good, next step is to fire up the debugger, and set a break point at
> that specific function. Run GDB, and use the GDB commands to modify or
> change a register.
> 
> BANG - you hit the break point, and you step into the function keep
> stepping till you find the function you need tomodify. Exit GDB, and
> hack away.
> 
> This method sure beats digging through source... and un-winding macros.

A word of caution.  You should also be looking over new targets such as 
the xstormy16.  Otherwise you may find that the techniques you've been 
borrowing are deprecated and not accepted in new targets.

enjoy,
Andrew