This is the mail archive of the
mailing list for the GDB project.
On Tue, Jan 22, 2002 at 02:57:03PM -0700, Kevin Buettner wrote:
> 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.)
So u_offsets are only used in the ptrace response for registers and not the
associated with the offsets needed to access registers fetched with the 'g' request.
Isn't that worthy of the comment just before the static int u_offsets decl:
/* These must match the order of the register names.
Some sort of lookup table is needed because the offsets associated
with the registers are all over the board. */
I would think similar offsets are needed for accessing registers provided
by the 'g' cmd for the gdb code to access a particular register. I would
have thought the ptrace data would be copied to the memory based copy
of the registers as layed out in ia64_register_names order.
> 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.
600 references to GDB_MULTI_ARCH. Lots of places to look. Does this
GDB_MULTI_ARCH paradigm meam that gdb isn't keeping registers in the
order defined by ia64_register_names. I would expect that the registers
available on the ia64 are archecture independant and the ia64_register_names
concept and storage should/could be common for all archectures.
> > 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 get the impression that theses can't be fetched with the 'g' command.
This seems to be insistant with the protocol.txt on the 'g' cmd:
o 'readAllRegisters': retrieve data from all available registers
Note: Register data are packed in the byte order of target.
This is the only known use of format 'bx'.
I expected the target could provide all available registers and use the
ia64_register_names array and the REGISTER_RAW_SIZE macro to determine there
offset in the response to the 'g' macro.
> > 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.
A simple check on the size of the array while filling it would seem prudent.
> > 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.
Why? Why not accept any register in the ia64_register_names array?
The "GDB Remote Serial Protocol Specification" seems to say that the
protocol should try to transfer as many registers as possible. Since
the kernel trap handler may not store registers in the same order
as the C compiler (SPARC for example on SunOS and Solaris) it would
seem more flexable for the stub to be able to provide as many registers
as possible with the 'g' response and then attempt to fill anyu unknown
values from the stack.
> > 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.
That's was the other possability I was considering, that it was expecting the registers to be
comming from the stack. Since kdb isn't providing the %bsp register in the register dump I
didn't provide it on my 1st shot at the response:
Entering kdb (current=0xe0000000009a0000, pid 0) on processor 0 due to Keyboard Entry
psr: 0x0000101008026018 ifs: 0x8000000000000915 ip: 0xe002000000410c50
unat: 0x0000000000000000 pfs: 0x0000000000000915 rsc: 0x0000000000000003
rnat: 0x8000000000000012 bsps: 0x000000000001003e pr: 0x0000000000014a59
ldrs: 0x0000000000000000 ccv: 0x0000000000000000 fpsr: 0x0009804c8a70433f
b0: 0xe002000000410d50 b6: 0xe002000000678c60 b7: 0xe00200000040a1c0
r1: 0xe002100000bb0000 r2: 0x0000000000000000 r3: 0xe000000001250000
r8: 0x0000000000000000 r9: 0x60000000000451d0 r10: 0x0000000000000000
r11: 0xc000000000000186 r12: 0xe0000000009a7e40 r13: 0xe0000000009a0000
r14: 0x0000000000000000 r15: 0x0000000000000001 r16: 0xc0000b00100000c0
r17: 0xe0000000009a0028 r18: 0xa000000000008320 r19: 0x0009804c8a70433f
r20: 0x00000000009a0000 r21: 0xe0020000004b34d0 r22: 0x80000000ffd5eed0
r23: 0x80000000ffd5ef10 r24: 0x80000000ffd5eec0 r25: 0x80000000ffd5ef20
r26: 0x80000000ffd5eee0 r27: 0xe0000000009a1298 r28: 0x0000000000014a99
r29: 0x0000000000000001 r30: 0x0000000000000000 r31: 0x0000000000000000
®s = e0000000009a7cb0
kdb> rd %bsp
bsp = 0x000000000001003e
I'll update skdb to cancatinate a few kdb commands together to collect ALL of the registers.
I'm not sure the %bsp will always provide access to the corect values of registers.
On SPARC the trap hander stores registers in a different place than the C compiler
uses. I assume the gdb stub is assuming C compiler offets for the registers it's
fetching from the %bsp. Is there a include file that defines this? It might make it
easier to sort this possability out.
Thanks, I expect this should fix one of the problems I was having.
Another bug/problem is that the function strtoul() seems to be returning an int (32 bits) and
not a 64bit unsigned long. I thought I might just add the code from a version like:
Looks like the code should work for ia64. Perhaps I should ask around at firstname.lastname@example.org.
BTW, I don't suppose there is an existing variable that I could set to have gdb spin till I have
time to attach to it prior to sending the 'g' cmd?