Spec; Was: tracepoints implementation: bug in byte code generating.

[Andrew Cagney <ac131313 at cygnus dot com>]

"J.T. Conklin" wrote:

> 4. COMMANDS
> 
> 4.1 REGISTER FETCH
> 
> input:
>         context_t       id;
>         int             offset;         offset within register data
>         int             length;         length of transfer
> 
> output:
>         int             status;
>         char            data[];
> 
> This command may yeild unpredicable results if context <id> has not
> been suspended.
> 
> issues:
>         This assumes a single flat address space for all registers.
>         It might be convienent to have separate (but potentially
>         overlapping) register files for integer registers, floating
>         point registers, system registers, miscellaneous registers,
>         etc.
> 
>         For example, one register file could contain the PC, FP, SP,
>         and whatever other registers are needed on a particular
>         architecture for GDB after a signal/exception/breakpoint
>         event.  This would solve the problem of what to return in
>         those events.

One problem with this on targets that like to switch their byte order
(yes not very many :-).
The register data is, by definition, target byte order dependant. 
Consequently, when GDB connects to the target it needs to know that
targets byte order for it to correctly interpret register values.

I suspect something that defines the register values in a byte-order
independant way may be better.  Something based more on the P packet
(but network byte ordered).

	Andrew