Re: ia64-stub.c

[Kevin Buettner <kevinb at redhat dot com>]

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
> long.

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.

> When
> 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.

Kevin