Re: RFC: Available registers as a target property

[Daniel Jacobowitz <drow at false dot org>]

On Sat, May 07, 2005 at 06:03:55PM +0200, Mark Kettenis wrote:
> Hi Daniel,
> 
> Your proposal sounds reasonable to me.  Do I understand correctly that
> the "set" keyword is supposed to be used to specify the contents of
> the `g' packet, or is there a somewhat broader use for them?

I was thinking of a broader use.  The only two "messages" I have worked
with so far are not g-packet related; they are more like shorthand for
groups of "reg" keywords.  If the target supplied "iwmmxt:36" then the
remote protocol would use p-packets based at register 0x36 to fetch the
iwmmxt registers.

This does raise an interesting question.  Should a target specify _all_
of its available registers this way, including a predefined
"set:standard:0"?  Or should the standard registers be implicit, unless
a set is specified which would conflict with them?

There's something to be said for requiring explicit reference to the
standard register set.  For instance, for MIPS it isn't clear whether
the 32-bit or 64-bit packet is "standard".  On the other hand, it's no
worse than the current situation if the target does not say.

Anyway, just a thought.  I think that the implicit reference is OK. But
for some targets, like MIPS, supplying an explicit reference will
probably be to the target's benefit, so it would provide "set:gprs32:0"
or "set:gprs64:0".

> Anyway, here are some random thoughts about things we might need to
> consider.  It's a bit i386 centric, the issues mostly are not.
> 
> * Is this going to allow us to make changes freely to the internal
>   layout of GDB's register cache?

The proposal, not specifically.  The implementation, yes.  It turns out
that after the last generation of cleanups this is quite simple to do.
All it required was a gdbarch method for mapping from GDB regnums to
remote protocol regnums; I preserved the assumption that the g packet
was contiguous and 0-based in the remote protocol numbering scheme,
which I think is a reasonable assumption.

> * How will we treat registers that the user might reasonably expect to
>   be there, but aren't made available by the target?
> 
> FreeBSD/i386 for example still has no way to get at the SSE registers,
> but has no problem executing code that uses its registers.  What do we
> do when the user says "print $xmm0" when connected to a FreeBSD/i386
> target?  Do we print:
> 
> (gdb) p $xmm0
> $1 = void
> 
> or are we going to try to print a more helpful message for
> well-known-but-unavailable registers?

Good question.  Unless additional work is done, you'd get void.  It
sounds like we need to define the registers with an "error" type; but
my limited experience with GCC's type system tells me that that can get
messy very quickly.  How about a list of unavailable register names,
provided by the architecture, and something parallel to the existing
user-regs.c code to generate the error message?

> * What do we do with pseudo registers?
> 
> The ia32 MMX registers are optional pseudo registers; they reinterpret
> the floating-point registers in a particular way.  As such they won't
> be transmitted between the target and GDB.  Yet it would be nice if we
> had a mechanism for the target to indicate whether MMX is available
> such that GDB knows if it should display the MMX registers or not.

This could either be a set keyword, or a new keyword; how about
"feature:mmx", defaulting to available if the new mechanism is not
used?

> * How does this interact with register groups?
> 
> Do we need a mechanism to indicate the register group to which a
> register belongs, or is the default register group behaviour good
> enough?

I hadn't thought about this.  It's a very complicated question.
One of the nice things about using the "set" notation for groups of
registers is that it allows and requires GDB to have a priori knowledge
of the use and meaning of those registers.  So in that case, the
target's existing reggroup method can handle them.  But for unknown
registers something else may be necessary.

The proposed register specifier was:
  reg:<NAME>:<PROTOCOL NUMBER>:<BITSIZE>:<TYPE>:<TARGET DATA>...

Perhaps an additional field, call it TAGS, which could include things
like "integer", "vector", "readonly" (this is important!  I forgot to
consider that).  I am not sure how save_reggroup/restore_reggroup
should be represented; does readonly cover all the cases where GDB
should not save/restore a register around function calls?  Probably
not.

[Reading this it occurs to me that the syntax above does not leave room
to define new common information in the future, because target data is
at the end.  I may need to rethink that structure.]

-- 
Daniel Jacobowitz
CodeSourcery, LLC