From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25354 invoked by alias); 18 Aug 2002 15:35:01 -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 25344 invoked from network); 18 Aug 2002 15:34:59 -0000 Received: from unknown (HELO localhost.redhat.com) (24.112.240.27) by sources.redhat.com with SMTP; 18 Aug 2002 15:34:59 -0000 Received: from ges.redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id B31F53D34; Sun, 18 Aug 2002 11:34:50 -0400 (EDT) Message-ID: <3D5FBE9A.6090009@ges.redhat.com> Date: Sun, 18 Aug 2002 08:35:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.0) Gecko/20020810 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Jacobowitz Cc: gdb@sources.redhat.com Subject: Re: Register Groups (again) References: <3D5EE0C6.7080902@ges.redhat.com> <20020818040145.GA26488@nevyn.them.org> <3D5F3484.8010807@ges.redhat.com> <20020818144433.GA17899@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-08/txt/msg00203.txt.bz2 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. 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. >> >>- 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 :-) > I was just suggesting that, with an attribute attached to each > register, we would know "for free" which ones were in a register group > for a given frame. That is already the case in the above. Well strictly speaking the above defines a large sparse 2d array (regnum X reggroup) and the presence of an element can be interpreted as having an attribute, or .... > Maybe I'm wrong, since I don't understand how they > could ever vary. At present they can't. thanks! Andrew