This is the mail archive of the
mailing list for the GDB project.
> 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.