From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15736 invoked by alias); 1 Feb 2003 17:09:26 -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 15728 invoked from network); 1 Feb 2003 17:09:26 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by 172.16.49.205 with SMTP; 1 Feb 2003 17:09:26 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 18f31r-0006vc-00; Sat, 01 Feb 2003 13:10:15 -0600 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 18f19V-0007ki-00; Sat, 01 Feb 2003 12:10:01 -0500 Date: Sat, 01 Feb 2003 17:09:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney Cc: Mark Kettenis , gdb@sources.redhat.com Subject: Re: RFC: Variables in blocks of registers Message-ID: <20030201171001.GB29662@nevyn.them.org> Mail-Followup-To: Andrew Cagney , Mark Kettenis , gdb@sources.redhat.com References: <200302011448.h11EmCkP001176@elgar.kettenis.dyndns.org> <3E3BEC50.9040104@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E3BEC50.9040104@redhat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-02/txt/msg00012.txt.bz2 On Sat, Feb 01, 2003 at 10:48:32AM -0500, Andrew Cagney wrote: > >On my i386-unknown-freebsd4.7 system, various tests in > >gdb.base/store.exp fail. The reason is related to the problem > >described in tdep/214; register variables that don't fit in a single > >variable. GDB assumes that such variables are stored in consecutive > >registers (according to its own register numbering scheme), which > >defenitely isn't what GCC uses on the i386. > > > >I'm looking into the suggestion Daniel made in tdep/214; teaching GDB > >about the order in which GCC allocates registers. There are several > >caveats though: > > > >* While GCC allocates its registers in a particular order right now, > > and always allocates blocks of consecutive registers, there is no > > guarantee that it will continue to do so. > > > >* I have no idea what other compilers do. If GDB's register numbering > > was chosen to match for example the System V compiler, teaching GDB > > GCC's register ordering will cause regressions on system that use > > it. We might play tricks with gcc_compiled of course. > > > >Since AFAIK GDB's internal register ordering is still not decoupled > >from the remote interface, I propose to add a new multi-arch function > >"next_regnum" which returns the next register to look in based on the > >register number passed to it as an argument. > > > >Comments? > > dwarf2 makes it possible to scatter a value across both memory and > registers. It's been proposed that the `struct value' be augmented with > something like `struct location' that knows how to find any sub > component of a value. However, right now GCC doesn't generate this. Probably because it would kill us. If I have any mental energy left after location lists, I may implement support for DW_OP_piece. Michael, I think the new multi-arch function is a good idea as long as it is a fallback from explicit debug info support, when we have such. I also think it needs a better name; but I'm not quite sure what. Hmm, that could be mitigated by adequate commenting. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer