This is the mail archive of the
mailing list for the GDB project.
On Jan 22, 12:51pm, Piet/Pete Delaney wrote:
> I expected them to be offsets into the registers stored in memory in the
> order specified by the ia64_register_names array in gdb/ia64-tdep.c.
See u_offsets in gdbserver/low-linux.c. These are the offsets
needed by the ptrace() operations PTRACE_PEEKUSER / PTRACE_POKEUSER.
I haven't tried it in a while, so these offsets may need some
updating. (They ought to match the offsets found in ia64-linux-nat.c.)
> I was also wondering if the macro REGISTER_RAW_SIZE in gdb/config/ia64/tm-ia64.h
> is correct. It's saying that all registers other that the floating point are 8 bytes
The macro in question is defined that way for gdbserver. Note that the
IA-64 target is multiarched and that the only definition that GDB uses
from config/ia64/tm-ia64.h is:
#define GDB_MULTI_ARCH 1
Anyway, REGISTER_RAW_SIZE is about a correct as it can be for gdbserver.
> I thought I read that the predict registers p0..p63 are 1 bit and packed into
> a single 64 bit chunk of memory.
They're packed into the pr register. ia64-tdep.c knows how to unpack
this register to give you discreet p0..p63 registers. (Note that from
GDB's standpoint these registers are read-only. A bit of work still
needs to be done to make them writable too.)
> I was wondering if by passing all of the registers in
> the ia64_register_names I was passing to much and clobbering some data structures.
It's possible. I seem to remember fixing something like this when I was
using it. It could be that it's broken again.
> I use the gdb info registers cmd it seems to know the values in first 31 registers from
> my response to the 'g' cmd but then tries to access memory for the rest.
This is correct.
> The memory location
> it's trys to access is an offset from the values it receives for the first 31 registers.
That's not right. It should be an offset from bsp.