ia64-stub.c

ia64-stub.c

[Piet/Pete Delaney]

I've searched various gdb source directorys and with Google for a
stub for communicating with ia64. I've monified a ia32 version of kdb 
stub that Andi Kleen sent me about half wroking with gdb on a ia64. 
The registeres after gr31 are giving me problems.

I have to sort out linking problems with gdb on my system to dig
into the problem. If could be that the GDB monitor.c code isn't
working right due to the definitions of register sizes for things
like the 1 bit prediction registers. It's difficult to be sure wihout
modifying the gdb code so I can have it wait till I attach gdb to it
prior to it's sending the 'g' packet. It's appears to be asking for memory 
locations relative to values in the 1st 32 general registers to find
the other registers. I haven't seen anything that explains that behavior,
so I likely have to checkout whats going on within gdb.

I just thought I'd make sure I'm not duplicating any existing work
that's available under the GNU license. I've looked for an exsiting 
ia64-stub.c and currently it looks like none are available. If not
I would think it would be easy after the user space skdb.c works for
ia64.

-piet

Re: ia64-stub.c

[Kevin Buettner]

On Jan 21,  1:00am, Piet/Pete Delaney wrote:

> I just thought I'd make sure I'm not duplicating any existing work
> that's available under the GNU license. I've looked for an exsiting 
> ia64-stub.c and currently it looks like none are available. If not
> I would think it would be easy after the user space skdb.c works for
> ia64.

I did add Linux/IA-64 support to gdbserver at one time, but I know of
no other existing work.  (From the rest of your message, it seems that
gdbserver isn't suitable for your purposes anyway.)

Kevin

Re: ia64-stub.c

[Piet/Pete Delaney]

Terminal too wide

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.

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. I thought I read that the predict registers p0..p63 are 1 bit and packed into
a single 64 bit chunk of memory. 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. 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. The memory location
it's trys to access is an offset from the values it receives for the first 31 registers.

I thought I'd fix some linking problems that seem to have surfaced in my gdb-5.1 work
space and place a loop in the code just prior to sending the 'g' packet. That way
gdb will wait till I attach to the gdb instance that skdb forked off.

-piet

Re: ia64-stub.c

[Kevin Buettner]

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

Re: ia64-stub.c

[Piet/Pete Delaney]

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 
	
	     Format: g
	
	     Reply:  <register_data-bx>
	
	     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
	[0]kdb> rd
	 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  
	&regs = e0000000009a7cb0

	[0]kdb> rd %bsp
	bsp = 0x000000000001003e
	[0]kdb> 

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:

	http://tcl.apache.org/sources/tcl/compat/strtoul.c.html
or
	binutils/binutils-2.11.2/libiberty/strtoul.c

Looks like the code should work for ia64. Perhaps I should ask around at glibc-cvs@sourceware.cygnus.com.



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?

-piet
	

Re: ia64-stub.c

[Kevin Buettner]

[dropped binutils from the cc; these aren't issues that the folks on
that list generally care about...]

On Jan 22,  3:35pm, Piet/Pete Delaney wrote:
> Subject: Re: ia64-stub.c
> 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.  */

Yeah.  That would indeed be a good idea.

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

To the best of my knowledge, that is correct.  At the moment, IA-64's
"g" packet is obviously not laid out very well since there's a lot of
wasted space.

I haven't been closely following what has been going on with remote.c,
but I think it may (soon?) be possible for a stub to (re)define the
layout of the "g" packet.  (Hopefully Andrew or  Daniel J will jump
in here and set me straight if I've said something incorrect.)

(Hint: Take a look at struct remote_state in remote.c.  It appears to
me that there's a little bit more work to do to be able to provide
something other than the default 1:1 mapping between g packet registers
and gdb register numbers, but the infrastructure is definitely there.)

> > 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[].

No.  The reason that I pointed out that REGISTER_RAW_SIZE in
config/ia64/tm-ia64.h only pertains to those gdbserver is because
the REGISTER_RAW_SIZE definition for gdb resides in ia64-tdep.c.
(See ia64_register_raw_size() in ia64-tdep.c.)

If you look, you'll see that the macro and the function do the
same thing.  (Which is a good thing or else the "g" packets
wouldn't match up.)

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

Yes.  See above.

> > > 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:

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

> > > 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? 

This means that the stub will need to have the same logic in it for
accessing r32-r127.  I felt it better to put it in only one place.

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

On the IA-64, r32-r127 are written to predictable places in the register
backing store.

> > > 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
> 	[0]kdb> rd
> 	 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  
> 	&regs = e0000000009a7cb0
> 
> 	[0]kdb> rd %bsp
> 	bsp = 0x000000000001003e
> 	[0]kdb> 
> 
> I'll update skdb to cancatinate a few kdb commands together to collect ALL of the registers.

That's fine.  But you should understand that some of the registers that
you collect will be ignored by gdb.

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

The location of where a particular register lives in the backing store with
respect to bsp is defined by the IA-64 architecture.  It is not compiler
dependent.  GDB is using BSP, CFM, and (sometimes) PFS to figure out the
locations of r32-r127.

[...]
> 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?

Do you perhaps want to do ``set remotetimeout 600'' or some such from gdb?

Kevin

Re: ia64-stub.c

[Piet/Pete Delaney]

On Tue, Jan 22, 2002 at 07:26:23PM -0700, Kevin Buettner wrote:
> > > > 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:
> 
> 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). 

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.

Isn't it possible to transfer predicate registers in the 'g' reply packet?

There isn't a 'pr' register defined in the ia64_register_names[] array,
so the convention isn't clear. If the REGISTER_RAW_SIZE macro indicates
they are 1 byte or perhaps 1 bit each, then the transfer is possible.
The REGISTER_RAW_SIZE implies that the 'g' packet reply should provide
the predict registers at 8 byte offsets like all of the other registers
other than the floats.

Unless the REGISTER_RAW_SIZE is correct for the predicate registers the
position of the most important registers (ip, psp) in the 'g' packet reply
isn't obvious. 

  "p0",   "p1",   "p2",   "p3",   "p4",   "p5",   "p6",   "p7",
  "p8",   "p9",   "p10",  "p11",  "p12",  "p13",  "p14",  "p15",
  "p16",  "p17",  "p18",  "p19",  "p20",  "p21",  "p22",  "p23",
  "p24",  "p25",  "p26",  "p27",  "p28",  "p29",  "p30",  "p31",
  "p32",  "p33",  "p34",  "p35",  "p36",  "p37",  "p38",  "p39",
  "p40",  "p41",  "p42",  "p43",  "p44",  "p45",  "p46",  "p47",
  "p48",  "p49",  "p50",  "p51",  "p52",  "p53",  "p54",  "p55",
  "p56",  "p57",  "p58",  "p59",  "p60",  "p61",  "p62",  "p63",

  "b0",   "b1",   "b2",   "b3",   "b4",   "b5",   "b6",   "b7",

  "vfp", "vrap",

  "pr", "ip", "psr", "cfm",							<<<--- ip

  "kr0",   "kr1",   "kr2",   "kr3",   "kr4",   "kr5",   "kr6",   "kr7",
  "", "", "", "", "", "", "", "",
  "rsc", "bsp", "bspstore", "rnat",						<<<--- bsp
  "", "fcr", "", "",
  "eflag", "csd", "ssd", "cflg", "fsr", "fir", "fdr",  "",
  "ccv", "", "", "", "unat", "", "", "",
  "fpsr", "", "", "", "itc",
  "", "", "", "", "", "", "", "", "", "",
  "", "", "", "", "", "", "", "", "",
  "pfs", "lc", "ec",


So even after I fetch the bsp and ip from kdb it's not clear where they
go in the 'g' packet reply. I had expected the u_offsets[] to provide
insight into the expected location but it seems the offsets are only
used for the ptrace interface.

Can I assume the REGISTER_RAW_SIZE macro is right and all registers other
than the floating point are 8 bytes? My experience up to now is that they
weren't. The ip register wasn't in the right place following this direct 
interpretation of the REGISTER_RAW_SIZE macro and the ia64_register_names.

-piet

Re: ia64-stub.c

[Kevin Buettner]

On Jan 22, 11:47pm, Piet/Pete Delaney wrote:

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

On IA-64, I think you will find that it's going to be *very* difficult
for your debugging interface to learn the values of r32-r127 without
using the backing store.

> 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'm willing to work with you to make this possible if you convince me that
it's worthwhile.  (I.e, if you can show me how your stub is going to
obtain these values without using the backing store.)

> Isn't it possible to transfer predicate registers in the 'g' reply packet?

You can if you wish, but at the moment they'll be ignored.

> There isn't a 'pr' register defined in the ia64_register_names[] array,
> so the convention isn't clear.

Please look again.  It's there.  (It comes just before "ip".)

> If the REGISTER_RAW_SIZE macro indicates
> they are 1 byte or perhaps 1 bit each, then the transfer is possible.

They're eight bytes apiece.  Why isn't the transfer possible with this
size?

> The REGISTER_RAW_SIZE implies that the 'g' packet reply should provide
> the predict registers at 8 byte offsets like all of the other registers
> other than the floats.

That's right.

You might also want to take a look at REGISTER_BYTE which'll give the
offsets more directly.

...

BTW, I think it might be worthwhile spending time working with the
maintainer of remote.c to make it possible to have a more abbreviated
"g" packet for IA-64 in which certain registers computed by either
means (r32-r127 from memory, p0-p63 from the bits of pr, etc) are
omitted.

Kevin

Re: ia64-stub.c

[Piet/Pete Delaney]

On Wed, Jan 23, 2002 at 04:14:48AM -0700, Kevin Buettner wrote:
> On Jan 22, 11:47pm, Piet/Pete Delaney wrote:
> 
> > > 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). 
> 
> On IA-64, I think you will find that it's going to be *very* difficult
> for your debugging interface to learn the values of r32-r127 without
> using the backing store.
> 
> > 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'm willing to work with you to make this possible if you convince me that
> it's worthwhile.  (I.e, if you can show me how your stub is going to
> obtain these values without using the backing store.)

kdb seems to return %r1 ... %r52, the code appears to be using the stack,
so it seems your right; at least for now. The function show_cur_stack_frame()
is getting involved in unwind stuff and I still have to read HP's ABI and
runtime arch stuff and perhaps I'll understand enough of it to make out
what show_cur_stack_frame() is doing. 



My background for the past few years is with SPARC, in this case I wrote
code that did produce the registers even when they didn't make it to the
backing store. I suspect the case is similar for ia64 but I'd only give
4:1 odds on it. On SPARC when we get a kernel stack overflow the registers
can't be pushed out to the stack because you hit a red zone. I added code
to map the redzone and flush the registers (if enabled). Even if not enabled
I had asm code to read the registers directly and store them in a register
save area for each register window. I got the impression that the ia64 hardware
is also defering the movement of the registers to memory like SPARC does as
so it would also have the same problem for regiter flushing bugs.

Anyway, it's not that important. Just seemed cleaner.




> > Isn't it possible to transfer predicate registers in the 'g' reply packet?
> 
> You can if you wish, but at the moment they'll be ignored.
Fine.

> 
> > There isn't a 'pr' register defined in the ia64_register_names[] array,
> > so the convention isn't clear.
> 
> Please look again.  It's there.  (It comes just before "ip".)

Great, so my code should have worked. I wonder why the ip register had
the wrong value in it. I'll redo the experiment tomarrow. I recall the
ip register being way off. 




> 
> > If the REGISTER_RAW_SIZE macro indicates
> > they are 1 byte or perhaps 1 bit each, then the transfer is possible.
> 
> They're eight bytes apiece.  Why isn't the transfer possible with this
> size?

It's fine, that what I was assuming base on the REGISTER_RAW_SIZE macro.


> 
> > The REGISTER_RAW_SIZE implies that the 'g' packet reply should provide
> > the predict registers at 8 byte offsets like all of the other registers
> > other than the floats.
> 
> That's right.
good, the codes consistant. 


> You might also want to take a look at REGISTER_BYTE which'll give the
> offsets more directly.
ok.


> 
> BTW, I think it might be worthwhile spending time working with the
> maintainer of remote.c to make it possible to have a more abbreviated
> "g" packet for IA-64 in which certain registers computed by either
> means (r32-r127 from memory, p0-p63 from the bits of pr, etc) are
> omitted.
When I sent truncated packets the 'g' command seemed to be happy,
so it may not be that important. I do recall the gcc code as noting
that the packet is truncated and taking error recovery; so I don't
know why it appeared to be ok to sned just the first 31 registers.

Looking at the registers that arrive inside gdb would help.

I seem to have messed something up and I'm getting problems with
the thread code. I thought it compiled right out of the box last time.
-------------------------------------------------------------------------------------------------------------------------------------------
 263 monica 04:34 ~/src/gdb/gdb-5.1/gdb> make
gcc -c -g -O2    -I. -I. -I./config -DHAVE_CONFIG_H -I./../include/opcode -I./../readline/.. -I../bfd -I./../bfd  -I./../include -I../intl -I./../intl  -DMI_OUT=1 -DUI_OUT=1 -Wimplicit -Wreturn-type -Wcomment -Wtrigraphs -Wformat -Wparentheses -Wpointer-arith -Wuninitialized  thread-db.c
In file included from /usr/include/thread_db.h:25,
                 from gdb_thread_db.h:2,
                 from thread-db.c:26:
/usr/include/pthread.h:163: parse error before `*'
/usr/include/pthread.h:165: `pthread_create' declared as function returning a function
/usr/include/pthread.h:166: parse error before `void'
/usr/include/pthread.h:169: parse error before `pthread_self'
/usr/include/pthread.h:169: warning: data definition has no type or storage class
/usr/include/pthread.h:172: parse error before `__thread1'
/usr/include/pthread.h:181: parse error before `__th'
/usr/include/pthread.h:187: parse error before `__th'
/usr/include/pthread.h:195: parse error before `*'
/usr/include/pthread.h:198: parse error before `*'
/usr/include/pthread.h:201: parse error before `*'
/usr/include/pthread.h:205: parse error before `*'
/usr/include/pthread.h:209: parse error before `*'
/usr/include/pthread.h:214: parse error before `*'
/usr/include/pthread.h:220: parse error before `*'
/usr/include/pthread.h:224: parse error before `*'
/usr/include/pthread.h:229: parse error before `*'
/usr/include/pthread.h:233: parse error before `*'
/usr/include/pthread.h:238: parse error before `*'
/usr/include/pthread.h:242: parse error before `*'
/usr/include/pthread.h:260: parse error before `*'
/usr/include/pthread.h:264: parse error before `*'
/usr/include/pthread.h:284: parse error before `*'
/usr/include/pthread.h:288: parse error before `*'
/usr/include/pthread.h:301: parse error before `__target_thread'
/usr/include/pthread.h:306: parse error before `__target_thread'
/usr/include/pthread.h:331: parse error before `*'
/usr/include/pthread.h:336: parse error before `*'
/usr/include/pthread.h:339: parse error before `*'
/usr/include/pthread.h:342: parse error before `*'
/usr/include/pthread.h:352: parse error before `*'
/usr/include/pthread.h:359: parse error before `*'
/usr/include/pthread.h:362: parse error before `*'
/usr/include/pthread.h:365: parse error before `*'
/usr/include/pthread.h:370: parse error before `*'
/usr/include/pthread.h:390: parse error before `*'
/usr/include/pthread.h:395: parse error before `*'
/usr/include/pthread.h:398: parse error before `*'
/usr/include/pthread.h:401: parse error before `*'
/usr/include/pthread.h:405: parse error before `*'
/usr/include/pthread.h:412: parse error before `*'
/usr/include/pthread.h:420: parse error before `*'
/usr/include/pthread.h:423: parse error before `*'
/usr/include/pthread.h:426: parse error before `*'
/usr/include/pthread.h:431: parse error before `*'
/usr/include/pthread.h:556: parse error before `*'
/usr/include/pthread.h:557: parse error before `)'
/usr/include/pthread.h:560: parse error before `__key'
/usr/include/pthread.h:563: parse error before `__key'
/usr/include/pthread.h:567: parse error before `__key'
/usr/include/pthread.h:576: parse error before `*'
/usr/include/pthread.h:577: parse error before `)'
/usr/include/pthread.h:591: parse error before `__thread'
In file included from gdb_thread_db.h:2,
                 from thread-db.c:26:
/usr/include/thread_db.h:234: parse error before `thread_t'
/usr/include/thread_db.h:234: warning: data definition has no type or storage class
/usr/include/thread_db.h:235: parse error before `thread_key_t'
/usr/include/thread_db.h:235: warning: data definition has no type or storage class
/usr/include/thread_db.h:242: parse error before `void'
/usr/include/thread_db.h:242: `td_key_iter_f' declared as function returning a function
/usr/include/thread_db.h:242: parse error before `void'
/usr/include/thread_db.h:255: parse error before `thread_t'
/usr/include/thread_db.h:255: warning: no semicolon at end of struct or union
/usr/include/thread_db.h:280: parse error before `}'
/usr/include/thread_db.h:280: warning: data definition has no type or storage class
/usr/include/thread_db.h:311: parse error before `pthread_t'
/usr/include/thread_db.h:370: parse error before `td_thrinfo_t'
/usr/include/thread_db.h:430: parse error before `__tk'
thread-db.c:81: parse error before `thread_t'
thread-db.c:99: parse error before `td_thrinfo_t'
thread-db.c: In function `thread_from_lwp':
thread-db.c:232: parse error before `ti'
thread-db.c:246: `ti' undeclared (first use in this function)
thread-db.c:246: (Each undeclared identifier is reported only once
thread-db.c:246: for each function it appears in.)
thread-db.c: In function `lwp_from_thread':
thread-db.c:256: parse error before `ti'
thread-db.c:268: `ti' undeclared (first use in this function)
thread-db.c: At top level:
thread-db.c:561: warning: type defaults to `int' in declaration of `td_thrinfo_t'
thread-db.c:561: parse error before `*'
thread-db.c: In function `attach_thread':
thread-db.c:568: `verbose' undeclared (first use in this function)
thread-db.c:569: `ptid' undeclared (first use in this function)
thread-db.c:574: `ti_p' undeclared (first use in this function)
thread-db.c:586: `th_p' undeclared (first use in this function)
thread-db.c: In function `check_event':
thread-db.c:655: parse error before `ti'
thread-db.c:673: `ti' undeclared (first use in this function)
thread-db.c: In function `thread_db_store_registers':
-------------------------------------------------------------------------------------------------------------------------------```
					"/usr/include/pthread.h"
-------------------------------------------------------------------------------------------------------------------------------```
    160 /* Create a thread with given attributes ATTR (or default attributes
    161    if ATTR is NULL), and call function START_ROUTINE with given
    162    arguments ARG.  */
    163 extern int pthread_create (pthread_t *__restrict __thread,
    164                            __const pthread_attr_t *__restrict __attr,
    165                            void *(*__start_routine) (void *),
    166                            void *__restrict __arg) __THROW;
    167 
-----------------------------------------------------------------------------------------------------------------------------------

Might have something to do with changing C compilers or trying out the latest libutils.

-piet

> 
> Kevin

Re: ia64-stub.c

[Andrew Cagney]

> 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