From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31348 invoked by alias); 29 Apr 2003 15:08:20 -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 31329 invoked from network); 29 Apr 2003 15:08:20 -0000 Received: from unknown (HELO crack.them.org) (146.82.138.56) by sources.redhat.com with SMTP; 29 Apr 2003 15:08:20 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 19AWid-00059r-00; Tue, 29 Apr 2003 10:08:32 -0500 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 19AWiJ-0007Pk-00; Tue, 29 Apr 2003 11:08:11 -0400 Date: Wed, 30 Apr 2003 03:37:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney Cc: Mark Kettenis , colins@google.com, gdb-patches@sources.redhat.com Subject: Re: re-ordered i386 regcache Message-ID: <20030429150810.GA12043@nevyn.them.org> Mail-Followup-To: Andrew Cagney , Mark Kettenis , colins@google.com, gdb-patches@sources.redhat.com References: <20030428153247.GA28501@nevyn.them.org> <3EAD51F1.8050605@redhat.com> <20030428161443.GA30324@nevyn.them.org> <3EAD58B8.2070003@redhat.com> <20030428192506.GA11978@nevyn.them.org> <3EADB095.2090409@redhat.com> <20030428233106.GA7307@nevyn.them.org> <3EADE027.90209@redhat.com> <20030429044506.GA11200@nevyn.them.org> <3EAE8C6B.2050403@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3EAE8C6B.2050403@redhat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-04/txt/msg00542.txt.bz2 On Tue, Apr 29, 2003 at 10:30:03AM -0400, Andrew Cagney wrote: > > >>>Of the above, at least the e500 issues I consider to be completely > >>>different; that's dealing with a very particular set of debug info that > >>>only has part of the register. That's a handy thing to solve in the > >>>register cache. Besides, it doesn't play sequential-register-numbering > >>>tricks. That was the whole point - the other numbers are way off in > >>>the 1200 range. > >>> > >>>I'd say the MIPS/i386 issues are also more like e500 than like this > >>>debug info ordering problem that we're talking about here. > > > >> > >>(are you sure you're refering to the correct architectures here?) > > > > > >Absolutely. > > The MIPS/i386 in the above be interpreted as i386 VS long long and not > i386/x86-64. The reword below clarified it. > > > I know the e500 situation (limited form of DW_OP_piece for > >64-bit registers), and both MIPS/MIPS and x86-64/i386 are trying to > >expose the same register in multiple ways. > > All three require a projection such that, assumed contigious, debug info > registers project onto raw registers. Isn't this what i386 has? I don't think so. All three need a view of registers slightly different from the "normal" one, but they don't have "assumed contiguous debug info registers". In fact in e500 they're assumed not-contiguous. > >>I'm not dismissing the value of the powerful pseudo technique that > >>>you've put together. It's really handy. I just don't think it's the > >>>answer to this problem. > > > >> > >>Going back to an earlier point it contains an i386 specific problem to > >>the i386. That way yet another hack doesn't get in the core code. > >>However, the knowledge of needing to handle that case does. > > > > > >If the choice is: > > - contain an i386 specific problem to i386 specific code by using a > > hack > > You mean that the cooked->raw mechanism is a hack? As I said above, the mechanism isn't. This use of it is. > > - provide a general, well-defined mechanism that at least now we only > > need for i386 > > (and I'm calling it a quick and tempoary hack, because it isn't the > final solution) Why not? This is my view of the road: - If we have multiple parts reported for a variable's location, use that. - Otherwise if the variable fits in the reported location, just use that. - Otherwise, use a defined mechanism to guess where the next part is. Instead of assuming "oh, it's a register, the next part must be in register ", which isn't true. Instead of fudging the regcache using cooked->raw in order to make this invalid assumption appear true. > GDB can't afford to accumulate yet more mechanisms just on the off > chance that a second architecture might just happen to need it. This is > how GDB ended up with so many architecture methods used by 1 (then zero) > targets (what's the harm in #define ...; #ifdef ...?). Instead, where > possible, target dependand code should start out by using existing > mechanisms; while the core is extended to use a more complete solution. The "more complete solution" won't solve the problem for the debug info we have today. That'll be around for a very long time. I'm more worried about the fragility of doing complex things with the regcache, which will have a maintenance cost every time we (you?) work on the regcache. When we could just do a simple method with low to no maintenance cost. Why _not_ acquire this mechanism? There's only a problem with buildup of not-thought-out and not-well-documented mechanisms, and this doesn't have to be either. > >I suppose I could mark both versions of %eax saved in i386's > >frame_get_saved_regs to fix the immediate problem... > > That is what was done (minus possible missed edge cases). > > Being able to project cooked onto raw registers at the frame level, > should simplify this. OK. If I ever get frustrated/bored enough, I'll try to fix the patch I posted. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer