From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6902 invoked by alias); 18 Aug 2002 16:18:16 -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 6895 invoked from network); 18 Aug 2002 16:18:15 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by sources.redhat.com with SMTP; 18 Aug 2002 16:18:15 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 17gSks-0002XO-00; Sun, 18 Aug 2002 11:18:18 -0500 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 17gSlN-0005hi-00; Sun, 18 Aug 2002 12:18:49 -0400 Date: Sun, 18 Aug 2002 09:18:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney Cc: gdb@sources.redhat.com Subject: Re: Register Groups (again) Message-ID: <20020818161849.GA21893@nevyn.them.org> Mail-Followup-To: Andrew Cagney , gdb@sources.redhat.com References: <3D5EE0C6.7080902@ges.redhat.com> <20020818040145.GA26488@nevyn.them.org> <3D5F3484.8010807@ges.redhat.com> <20020818144433.GA17899@nevyn.them.org> <3D5FBE9A.6090009@ges.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D5FBE9A.6090009@ges.redhat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2002-08/txt/msg00204.txt.bz2 On Sun, Aug 18, 2002 at 11:34:50AM -0400, Andrew Cagney wrote: > http://sources.redhat.com/ml/gdb/2001-02/msg00268.html > >>Sorry, I think I'm missing something. I don't see a difference. > >>s/reggroup/regattrib/? > > > > > >In your scheme, you have reggroups as a structure. In mine, you'd have > >a set of flags associated with each register. Not a fundamental > >difference, but it seems a little more straightforward. As I said, > >just a passing thought. > > (NickD's original proposal had reggroups implemented as integers.) > > Ah, yes, I even considered proposing flags. Looking through the > responses for NickD's proposoal (before it went off on a tangent :-( ) I > think it is evident that people liked the ability to define their own > groups over and above the predefined ones. On a per-target basis? We could simply reserve flags for "target-specific use"... I don't know which would be cleaner. You were probably on the right track with groups at that point. But my primary point was non-orthogonal flags. Particularly the kernel-vs-usermode thing, which the SH-Linux people have done some fairly ugly things to handle. (Not contributed, I think) > Since I had flags in mind, my query interface looks like: > > register_reggroup_p (gdbarch, regnum, group) > vs > register_reggroups (gdbarch, regnum) & group) > > where as NickD's proposal used iterators. I figure that if the overhead > of iterating through NUM_REGS+NUM_PSEUDO_REGS becomes measurable then > someone will comeup with a new interface. Sounds fine to me. > >>>>- how it relates to frames > >>>> > >>>>It currently assumes that the register groups are identical between > >>>>frames :-/ > > > >> > >>i.e.: > >> register_reggroup_p(gdbarch,regnum,group) > >>rather than: > >> frame_register_reggroup_p(frame,regnum,group) > >> > > > >>>With an attribute scheme, once we know which registers are present in a > >>>frame we'd know which (say) float registers are present in that > >>>frame... > > > >> > >>Now I'm really confused. How is this not possible using what I described? > > > > > >I don't understand why this should be dependent on the frame? If > >you're talking about a hypothetical future GDB where the gdbarch varies > >by frame, then we'll have to know the gdbarch anyway... > > (A frame ``has a'' architecture.) > > Consider trying to unwind an IA-64 kernel stack back through to an IA-32 > user land. > > At present things like Arm, MIPS and SH (pretty extreem) handle this > using a single architecture object. At some point, it is going to > become easier to have a per-frame architecture and allow them to vary. > > I'm trying to avoid doing anything that precludes that possibility (with > out making a developers life unreasonable :-) Sure, a frame has an architecture. But I don't think this interface should use the frame directly; I think it should use the architecture as you originally suggested, since that is the only piece of data in the frame it should be allowed to depend on. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer