From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22633 invoked by alias); 23 Apr 2002 14:32:28 -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 22596 invoked from network); 23 Apr 2002 14:32:25 -0000 Received: from unknown (HELO nevyn.them.org) (128.2.145.6) by sources.redhat.com with SMTP; 23 Apr 2002 14:32:25 -0000 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 1701LH-0001vI-00; Tue, 23 Apr 2002 10:32:27 -0400 Date: Tue, 23 Apr 2002 07:32:00 -0000 From: Daniel Jacobowitz To: Michal Ludvig Cc: gdb-patches@sources.redhat.com Subject: Re: [RFA] New bitflags type and eflags on i386/x86-64 Message-ID: <20020423103227.A6914@nevyn.them.org> Mail-Followup-To: Michal Ludvig , gdb-patches@sources.redhat.com References: <3CC42916.9080001@suse.cz> <20020422114523.A6524@nevyn.them.org> <3CC43569.1040008@suse.cz> <20020423002810.A13864@nevyn.them.org> <3CC55FF9.3030008@suse.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3CC55FF9.3030008@suse.cz> User-Agent: Mutt/1.3.23i X-SW-Source: 2002-04/txt/msg00847.txt.bz2 On Tue, Apr 23, 2002 at 03:22:01PM +0200, Michal Ludvig wrote: > Daniel Jacobowitz wrote: > >On Mon, Apr 22, 2002 at 06:08:09PM +0200, Michal Ludvig wrote: > > > >>Daniel Jacobowitz wrote: > >unpack_long returns LONGEST. Why not have a flagword bigger than that? > > Where would you store it? And what type would you use for it? In memory, of course, and TYPE_CODE_SET :) > >>>I would prefer if you instead added > >>>support to c-valprint.c for something like Pascal's TYPE_CODE_SET (see > >>>p-valprint.c) and used that. It should be exactly what you're looking > >>>for. Basically, you create an enum describing the bit position (not > >>>mask) for each flag, and then call create_set_type with that type as > >>>the domain_type. > > I still don't understand these "nested" types :-( > > Is this a correct procedure? > - create an ENUM type > - set its nfields to number of bits of my flagword. > - allocate space for its fields[bits] and fill all fields with propper > position of the bit and its name. > - call create_set_type with the just created enum > > Is that all? I haven't tried it. That looks right to me, though. > Than I have some questions: > - What should be in the 'length' field of ENUM and what in lenght field > of SET? Doesn't matter (probably 0) and set by create_set_type, respectively. > - Should I set ENUM's entries (fields) for all bits in the flagword (eg. > 32) or is it enough to set only used ones and ignore the rest when > printing it (I'd prefer this approach). Well, up to you. It occurs to me - there is a disadvantage of using types. Will they be printed according to the "current" language? What happens with your TYPE_CODE_FLAGS patch if you 'set language pascal' before 'info registers'? Should we always print registers as C types? > BTW How do I extract a value of the variable using unpack_long()? I > tried to call it both with type and elttype but always got a wrong > result. Can it be because of wrong lenght fields in these types? No idea. > > >>I was about to use TYPE_CODE_SET, but I don't know how to add names to > >>its elements. With FLAGS they are written during initialization. Also > >>FLAGS is more simple than SET appears to be. Unfortunately I used pascal > >>too long ago to remember how the set type behaves like... > > > >I described that in my message. If you create an enum first, > >everything should just work. I don't see the virtue in adding another > >type here. > > Actually, I do. Type FLAG perfectly and cleanly does what it was ceated > for and is self-describing. Using SET seems to be less synoptical. Also > SET is used so rarely in gdb that it isn't a defact standard for such > things. But it serves the precise same purpose and already exists! I don't really care, though (and can't approve things in this area anyway). You might want to get a comment from someone who can before you go further. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer