From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22494 invoked by alias); 1 Feb 2003 15:48:34 -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 22487 invoked from network); 1 Feb 2003 15:48:33 -0000 Received: from unknown (HELO localhost.redhat.com) (24.157.209.173) by 172.16.49.205 with SMTP; 1 Feb 2003 15:48:33 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 476EF3C9D; Sat, 1 Feb 2003 10:48:32 -0500 (EST) Message-ID: <3E3BEC50.9040104@redhat.com> Date: Sat, 01 Feb 2003 15:48:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.1) Gecko/20021211 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Kettenis Cc: gdb@sources.redhat.com Subject: Re: RFC: Variables in blocks of registers References: <200302011448.h11EmCkP001176@elgar.kettenis.dyndns.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-02/txt/msg00009.txt.bz2 > 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. Andrew