Mirror of the gdb mailing list
 help / color / mirror / Atom feed
* Re: A better register interface
@ 2001-02-15 16:46 Peter Reilley
  2001-02-15 18:20 ` Andrew Cagney
  0 siblings, 1 reply; 10+ messages in thread
From: Peter Reilley @ 2001-02-15 16:46 UTC (permalink / raw)
  To: GDB Discussion

I have a request for a feature that I have needed.
I would like to have a target API that allowed the
target code to parse the reg name string and return
the reg value if it existed or an error if it did not
exist.   The same for a write register API.

In the case of the PowerPC, there are SPR registers
that vary from one processor implementation to another.
The SPR address space is 2K, but is only sparsely populated.
Too many to include in NUM_RAW_REGISTERS.   If they could be
created on the fly, the problem would be solved.
Then, the "info reg" command would only print
the defined registers but the SPR registers
would still be accessible.

Thanks,
Pete.


-----Original Message-----
From: Andrew Cagney <ac131313@cygnus.com>
To: GDB Discussion <gdb@sources.redhat.com>
Date: Wednesday, February 14, 2001 11:40 PM
Subject: A better register interface


>Hello,
>
>As many people will tell you GDB's current register interface/model is
>so large you can comfortably drive a road train through it.
>
>Right now there are roughly the following interfaces:
>
>On the target side:
>
> o supply_register()
>
> o register_buffer()
> (nee register_buffer[])
>
>While on the GDB side, there are a number of ways of getting at the
>cache and all are used randomly.
>
> o read_register()
>
> o write_register()
>
> o get_saved_register()
>
> o find_saved_register()
>
>but quickly decays into:
>
> o {read,write}_register_pid()
>
> o read_register_bytes()
>
> o register_buffer()
>
> o {read,write}_register_gen() 
> 
>Accompanying this there is the split of GDB's registers into virtual,
>raw, normal? and pseudo.  Pseudo registers are significant as, in theory
>at least, they are not backed by real bytes but instead constructed on
>the fly using bits and bytes from other registers.  Well nice theory :-/
>
>Associated with this are a number of bugs.  The most common are:
>
> o you can't get a complex pseudo
> register from a saved frame
>
> o you can't modify a complex pseudo
>
> o you can only print complex psuedos
> by a hack - have it backed by a
> read only buffer.
>
> o the RAW_REGISTER_BYTE() macro determines
> everything including the format of the
> remote G packet.
>
>(a complex pseudo is one that is constructed from random bits from the
>register cache or stack).
>
>I'd like to bite the bullet and see GDB rid of this mess.  As a starting
>point, I'd like to propose the following as the minimal interface and
>try to cut things down so that there is only a minimal number of calls
>into the register cache.  Hopefully this proposal would also help better
>clarify the register interfaces.  In this I've borrowed from several
>recent postings (Steven Johnson and Nick Duffek) along with too many bad
>experiences with the existing model.
>
>--
>
>While eventually, I'd like to see a clear separation between the two
>sides of the register cache - the target side which supplies raw bytes
>and the gdb/core side which uses values and register names, it won't be
>possible for some time.  Instead, I'd like to see the existing REGNUM
>space structured as:
>
>    core gdb |     target side
>
> 0
> .
> . raw register space
> .
> NUM_RAW_REGISTERS
> .
> . any additional non raw registers
> .
>   NUM_COOKED_REGISTERS
>
>There are 0..NUM_RAW_REGISTERS raw registers that contain raw register
>bytes supplied by the target.
>
>The target side is only allowed to access 0..NUM_RAW_REGISTERS using
>functions like:
>
> supply_raw_register(RAWNUM, buf, sizeof buf)
> set_raw_register_state (RAWNUM, that register valid stuff);
> fetch_raw_register(RAWNUM, buf, sizeof buf)
> something for value changed?
> raw_register_size(RAWNUM)
> raw_register_name(RAWNUM)
>
>raw_register_name() is significant as it is new.  It is there for two
>reasons:
>
> o it allows the implementation
> of a simple but meanginful
> ``info raw-registers''
> command that would just dump
> the raw buffer
>
> o it provides abstract names to
> each target side register.
>
> remote.c would then be able to
> describe its G packet in terms
> of ``target names'' rather than
> magic numbers and mysterious offsets.
> (eg set G-packet-format r0:4,4;r1:12,8;...)
>
>
>There are 0..NUM_COOKED_REGISTERS cooked/pseudo registers that supply
>register values to core-gdb.
>
>gdb-core would be allowd to access cooked registers.  Cooked register
>methods would have frame associated with them (NULL implies no frame but
>must be handled).
>
> cooked_register_name(frame, REGNUM)
> cooked_register_type(frame, REGNUM)
> provides the size implicitly
> read_cooked_register(frame, REGNUM, buf, sizeof buf)
> write_cooked_register(frame, REGNUM, buf, sizeof buf)
> along with a few others such as:
> cooked_register_attrib_p (frame, REGNUM, some attribute - is FP?)
>
>thoughts.  The key thing is that, the interface is minimized.  This
>would mean that chunks of GDB would need re-implemented.  But as they
>say, no pain, no gain.
>
> Andrew
>


^ permalink raw reply	[flat|nested] 10+ messages in thread
* A better register interface
@ 2001-02-14 20:39 Andrew Cagney
  2001-02-14 22:17 ` Nick Duffek
                   ` (2 more replies)
  0 siblings, 3 replies; 10+ messages in thread
From: Andrew Cagney @ 2001-02-14 20:39 UTC (permalink / raw)
  To: GDB Discussion

Hello,

As many people will tell you GDB's current register interface/model is
so large you can comfortably drive a road train through it.

Right now there are roughly the following interfaces:

On the target side:

	o	supply_register()

	o	register_buffer()
		(nee register_buffer[])

While on the GDB side, there are a number of ways of getting at the
cache and all are used randomly.

	o	read_register()

	o	write_register()

	o	get_saved_register()

	o	find_saved_register()

but quickly decays into:

	o	{read,write}_register_pid()

	o	read_register_bytes()

	o	register_buffer()

	o	{read,write}_register_gen()		
		
Accompanying this there is the split of GDB's registers into virtual,
raw, normal? and pseudo.  Pseudo registers are significant as, in theory
at least, they are not backed by real bytes but instead constructed on
the fly using bits and bytes from other registers.  Well nice theory :-/

Associated with this are a number of bugs.  The most common are:

	o	you can't get a complex pseudo
		register from a saved frame

	o	you can't modify a complex pseudo

	o	you can only print complex psuedos
		by a hack - have it backed by a
		read only buffer.

	o	the RAW_REGISTER_BYTE() macro determines
		everything including the format of the
		remote G packet.

(a complex pseudo is one that is constructed from random bits from the
register cache or stack).

I'd like to bite the bullet and see GDB rid of this mess.  As a starting
point, I'd like to propose the following as the minimal interface and
try to cut things down so that there is only a minimal number of calls
into the register cache.  Hopefully this proposal would also help better
clarify the register interfaces.  In this I've borrowed from several
recent postings (Steven Johnson and Nick Duffek) along with too many bad
experiences with the existing model.

--

While eventually, I'd like to see a clear separation between the two
sides of the register cache - the target side which supplies raw bytes
and the gdb/core side which uses values and register names, it won't be
possible for some time.  Instead, I'd like to see the existing REGNUM
space structured as:

    core gdb 	|     target side

		0
		.
		. raw register space
		.
	NUM_RAW_REGISTERS
		.
		. any additional non raw registers
		.
	  NUM_COOKED_REGISTERS

There are 0..NUM_RAW_REGISTERS raw registers that contain raw register
bytes supplied by the target.

The target side is only allowed to access 0..NUM_RAW_REGISTERS using
functions like:

	supply_raw_register(RAWNUM, buf, sizeof buf)
	set_raw_register_state (RAWNUM, that register valid stuff);
	fetch_raw_register(RAWNUM, buf, sizeof buf)
	something for value changed?
	raw_register_size(RAWNUM)
	raw_register_name(RAWNUM)

raw_register_name() is significant as it is new.  It is there for two
reasons:

	o	it allows the implementation
		of a simple but meanginful
		``info raw-registers''
		command that would just dump
		the raw buffer

	o	it provides abstract names to
		each target side register.

		remote.c would then be able to
		describe its G packet in terms
		of ``target names'' rather than
		magic numbers and mysterious offsets.
		(eg set G-packet-format r0:4,4;r1:12,8;...)


There are 0..NUM_COOKED_REGISTERS cooked/pseudo registers that supply
register values to core-gdb.

gdb-core would be allowd to access cooked registers.  Cooked register
methods would have frame associated with them (NULL implies no frame but
must be handled).

	cooked_register_name(frame, REGNUM)
	cooked_register_type(frame, REGNUM)
		provides the size implicitly
	read_cooked_register(frame, REGNUM, buf, sizeof buf)
	write_cooked_register(frame, REGNUM, buf, sizeof buf)
	along with a few others such as:
	cooked_register_attrib_p (frame, REGNUM, some attribute - is FP?)

thoughts.  The key thing is that, the interface is minimized.  This
would mean that chunks of GDB would need re-implemented.  But as they
say, no pain, no gain.

	Andrew


^ permalink raw reply	[flat|nested] 10+ messages in thread
end of thread, other threads:[~2001-02-26 16:05 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-02-15 16:46 A better register interface Peter Reilley
2001-02-15 18:20 ` Andrew Cagney
2001-02-16  6:48   ` Andrew Cagney
  -- strict thread matches above, loose matches on Subject: below --
2001-02-14 20:39 Andrew Cagney
2001-02-14 22:17 ` Nick Duffek
2001-02-15  3:37   ` Eli Zaretskii
2001-02-15  7:43     ` Nick Duffek
2001-02-15 18:54 ` Andrew Cagney
2001-02-26 14:01 ` Nick Duffek
2001-02-26 16:05   ` Andrew Cagney

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox