Re: ia64-stub.c

[Andrew Cagney <ac131313 at cygnus dot com>]

> As noted above, there are a number of registers which are included in
>> the "g" packet which the IA-64 port disregards.  r32-r127 are retrieved
>> using an offset from BSP from the backing store (i.e, from memory).
>> The predicate registers are transferred in a single 64 bit word (the
>> pr register) and are split out to show individual 1-bit registers
>> by gdb.  Something similar occurs for the NaT bits.  Most of these
>> are indicated via a -1 in the u_offsets[] array.  (Some of these,
>> however, are simply not retrievable via the ptrace interface and
>> are therefore marked with -1.)
> 
> 
> In the kernel the registers may not always flushed out the the backing store.
> In a SPARC kernel a 2nd level trap is required for the kernel code to flush
> the registers to the backing store. A similar case may apply to ia64. Like
> in the even of a stack overflow (backing store isn't mapped). 


Please take anything you see in the SPARC with a grain of salt.  If 
someone were to implement the SPARC target today I think they would 
implement it very differently.  The register read/write architecture 
methods would most likely be used.  Those methods let an architecture 
map a register onto either memory or the register cache.


> I would think it preferable for gdb to accept values in the 'g' packet
> and if it doesn't receive a copy of the r32-r127 registers to then try
> to fetch them using an offset from the BSP.


I don't think that is possible with a G packet.  Several problems arise:

- If the target sends a short G packet then GDB assumes remaining 
registers are zero.

- on the wierd side, if a target supports the register-write packet GDB 
will write to those regsters.  However, if the register-write packet 
isn't supported then GDB won't write to them :-/

- there is a register unavailable indication (XXX in a G packet) but I 
don't know that its semantics extend to this case

I think persuing either a read-register packet (proposal posted some 
time back but never followed through) or, as kevin suggested, just 
saving the registers would be better.

enjoy,
Andrew