Re: ia64-stub.c

[Piet/Pete Delaney <piet at sgi dot com>]

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