This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: RFC: Available registers as a target property
Daniel,
(Sorry for the delay, but I had some mailer problems....)
Daniel Jacobowitz wrote:
GDB _wouldn't_ need to
know about the particular configuration. All the configuration
information GDB needed, it could retrieve from the daemon.
Hmmm... I have to think about it. It sounds like it could work. But that
would be too easy, wouldn't it ;-)
Sometimes, GDB needs configuration information and the target can
supply it. Sometimes (apparently) the target needs information about
its own configuration and GDB can supply it.
I think we'll always be doing one or the other; one endpoint needs to
have enough information for both rather than GDB needing to negotiate
with the target. That suggests that the two configuration steps should
be implemented independently.
Agreed.
The options are to tell GDB about this directly, or to have the OCD
tell GDB about the real properties of the target. I obviously prefer
the latter when possible, because it allows GDB to gracefully handle
binaries built for one configuration, and run on another configuration
where they still work (but may be somehow affected by state they can
not see).
This actually goes back to your comment above - I think. How do you
tread 'pseudo' registers? Would it make sense to add 'flags' to the
'set' command?
set:<NAME>:<PROTOCOL NUMBER>[:<FLAGS>]
In our case (Tensilica-Xtensa), we have a non-sequential register
encoding and use the pnum <-> regnum mapping. For example, all address
registers might have a pnum 0x10XX, special register 0x11XX, etc.
Do you use a 'g' packet at all? Certainly you're free not to. If you
do, then I'm not sure what it means with non-sequential pnums.
At this point, we don't. However, with the changes you are planing to
implement (thanks, btw.), we could probably use g/G again.
In cases where pnum is not sequential, you would also need a 'reverse'
lookup function to get the register from pnum, something like this:
static struct packet_reg *
packet_reg_from_pnum (struct remote_state *rs, LONGEST pnum)
You mean, like the function of that same name and implementation
already in remote.c? Otherwise I'm not sure what you're talking about.
Oops... I wasn't sure if I was looking at our code or the original GDB
sources. It looks like GDB has support for non-sequential pnums, but
doesn't allow to assign them from gdbarch.
~Chris