From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4068 invoked by alias); 23 Apr 2002 04:28:31 -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 4050 invoked from network); 23 Apr 2002 04:28:29 -0000 Received: from unknown (HELO nevyn.them.org) (128.2.145.6) by sources.redhat.com with SMTP; 23 Apr 2002 04:28:29 -0000 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 16zruV-0003f1-00; Tue, 23 Apr 2002 00:28:11 -0400 Date: Mon, 22 Apr 2002 21:28: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: <20020423002810.A13864@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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3CC43569.1040008@suse.cz> User-Agent: Mutt/1.3.23i X-SW-Source: 2002-04/txt/msg00822.txt.bz2 On Mon, Apr 22, 2002 at 06:08:09PM +0200, Michal Ludvig wrote: > Daniel Jacobowitz wrote: > >On Mon, Apr 22, 2002 at 05:15:34PM +0200, Michal Ludvig wrote: > > > >>Hi all, > >>I've created a new typecode TYPE_CODE_FLAGS with appropriate functions > >>and used it in builtin_type_i386_eflags type. I did this to be able to > >>print i386's and x86-64's FLAGS register in a symbolic form, instead of > >>printing it in a hexadecimal and decimal notation. > >> > >First of all, please include ChangeLog entries; it makes patches easier > >to digest quickly. > > I did a while later (as soon as I noticed it went without ChangeLog). > > >Second, I see that you assume a TYPE_CODE_FLAGS type is the size of a > >long. I'm not fond of that. > > unpack_long() returns type LONGEST. > IMHO it is the biggest integer I can have, isn't it? I don't assume it > is just 'long'... unpack_long returns LONGEST. Why not have a flagword bigger than that? > >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 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. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer