From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31277 invoked by alias); 23 Jan 2002 07:47:37 -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 31237 invoked from network); 23 Jan 2002 07:47:34 -0000 Received: from unknown (HELO zok.sgi.com) (204.94.215.101) by sources.redhat.com with SMTP; 23 Jan 2002 07:47:34 -0000 Received: from rock.csd.sgi.com (fddi-rock.csd.sgi.com [130.62.69.10]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.1) with ESMTP id g0N7lXo20238; Tue, 22 Jan 2002 23:47:33 -0800 Received: from piet1.csd.sgi.com (piet1.csd.sgi.com [130.62.73.47]) by rock.csd.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id XAA47160; Tue, 22 Jan 2002 23:47:33 -0800 (PST) Received: (from piet@localhost) by piet1.csd.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id XAA59431; Tue, 22 Jan 2002 23:47:32 -0800 (PST) Date: Tue, 22 Jan 2002 23:47:00 -0000 From: Piet/Pete Delaney To: Kevin Buettner Cc: gdb@sources.redhat.com, Piet Delaney Subject: Re: ia64-stub.c Message-ID: <20020122234732.A59205@sgi.com> 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> <1020123022623.ZM7453@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1020123022623.ZM7453@localhost.localdomain> User-Agent: Mutt/1.3.23i X-SW-Source: 2002-01/txt/msg00254.txt.bz2 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