From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11814 invoked by alias); 26 Apr 2003 02:44:43 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 11807 invoked from network); 26 Apr 2003 02:44:41 -0000 Received: from unknown (HELO localhost.redhat.com) (66.30.197.194) by sources.redhat.com with SMTP; 26 Apr 2003 02:44:41 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id A73E82B2F; Fri, 25 Apr 2003 22:44:37 -0400 (EDT) Message-ID: <3EA9F295.2090803@redhat.com> Date: Sat, 26 Apr 2003 03:32:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030223 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Jacobowitz Cc: Mark Kettenis , colins@google.com, gdb-patches@sources.redhat.com Subject: Re: patch for printing 64-bit values in i386 registers; STABS format References: <200304242231.h3OMVqM13587@dhcp357.corp.google.com> <20030425002744.GA9492@nevyn.them.org> <200304252121.h3PLLD8I000461@elgar.kettenis.dyndns.org> <20030425213548.GA22505@nevyn.them.org> <3EA9B6AE.90001@redhat.com> <20030426015010.GA25355@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-04/txt/msg00503.txt.bz2 >> It's possible to fix this without adding an architecture method, or >> implementing location expressions (the penny just dropped). The basic >> problem is the same as for the MIPS - need a custom register area. Hence: >> >> - define a sequence of nameless cooked ([NUM_REGS .. >> NUM_REGS+NUM_PSEUDO_REGS) range) registers ordered the way stabs would >> like them >> - modify the existing stabs_regnum_to_regnum to map the messed up >> registers onto those values > > > Could you explain why you think that (which I personally think is much > grosser, since it perpuates the assumption that values continue into > sequential registers) is a better solution than Mark's approach? The assumption that values continue into sequential registers is, unfortunatly. how stabs works :-( The consequence of `without adding an architecture method' is that it confinds the i386 case to the i386. The MIPS case, which is far worse, will also be the same (at present there is a slew of per-architecture methods that can be eliminated when the MIPS switches to the same strategy). Andrew