From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31920 invoked by alias); 23 Jan 2002 15:29:53 -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 31884 invoked from network); 23 Jan 2002 15:29:51 -0000 Received: from unknown (HELO localhost.cygnus.com) (24.114.42.213) by sources.redhat.com with SMTP; 23 Jan 2002 15:29:51 -0000 Received: from cygnus.com (localhost [127.0.0.1]) by localhost.cygnus.com (Postfix) with ESMTP id 65E2F3C81; Wed, 23 Jan 2002 10:29:50 -0500 (EST) Message-ID: <3C4ED6EE.7000502@cygnus.com> Date: Wed, 23 Jan 2002 07:29:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:0.9.7) Gecko/20020103 X-Accept-Language: en-us MIME-Version: 1.0 To: Piet/Pete Delaney Cc: Kevin Buettner , gdb@sources.redhat.com Subject: Re: ia64-stub.c 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> <20020122234732.A59205@sgi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-01/txt/msg00264.txt.bz2 > 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