From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7876 invoked by alias); 23 Jan 2002 02:27:59 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 7836 invoked from network); 23 Jan 2002 02:27:58 -0000 Received: from unknown (HELO cygnus.com) (205.180.230.5) by sources.redhat.com with SMTP; 23 Jan 2002 02:27:58 -0000 Received: from cse.cygnus.com (cse.sfbay.redhat.com [205.180.230.236]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id SAA08963; Tue, 22 Jan 2002 18:27:52 -0800 (PST) Received: (from kev@localhost) by cse.cygnus.com (8.11.6/8.11.6) id g0N2QNH07454; Tue, 22 Jan 2002 19:26:23 -0700 Date: Tue, 22 Jan 2002 18:27:00 -0000 From: Kevin Buettner Message-Id: <1020123022623.ZM7453@localhost.localdomain> In-Reply-To: Piet/Pete Delaney "Re: ia64-stub.c" (Jan 22, 3:35pm) References: <20020121010007.C54701@sgi.com> <1020121214310.ZM2318@localhost.localdomain> <20020122105652.A57552@sgi.com> <1020122190037.ZM5902@localhost.localdomain> <20020122121956.B57552@sgi.com> <20020122125127.A57796@sgi.com> <1020122215702.ZM6622@localhost.localdomain> <20020122153522.A57609@sgi.com> X-Mailer: Z-Mail (4.0.1 13Jan97 Caldera) To: Piet/Pete Delaney Subject: Re: ia64-stub.c Cc: gdb@sources.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2002-01/txt/msg00253.txt.bz2 [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 > ®s = 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