From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19145 invoked by alias); 29 Apr 2002 17:17:12 -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 18820 invoked from network); 29 Apr 2002 17:15:52 -0000 Received: from unknown (HELO nevyn.them.org) (128.2.145.6) by sources.redhat.com with SMTP; 29 Apr 2002 17:15:52 -0000 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 172EkE-0000Lk-00; Mon, 29 Apr 2002 13:15:22 -0400 Date: Mon, 29 Apr 2002 10:17:00 -0000 From: Daniel Jacobowitz To: Pierre Muller Cc: Michal Ludvig , gdb-patches@sources.redhat.com Subject: Re: [RFA] New bitflags type and eflags on i386/x86-64 Message-ID: <20020429131522.A1298@nevyn.them.org> Mail-Followup-To: Pierre Muller , Michal Ludvig , gdb-patches@sources.redhat.com References: <3CC42916.9080001@suse.cz> <3CC42916.9080001@suse.cz> <4.2.0.58.20020429180717.020bacb0@ics.u-strasbg.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4.2.0.58.20020429180717.020bacb0@ics.u-strasbg.fr> User-Agent: Mutt/1.3.23i X-SW-Source: 2002-04/txt/msg01126.txt.bz2 On Mon, Apr 29, 2002 at 06:52:08PM +0200, Pierre Muller wrote: > At 17:45 22/04/2002 , Daniel Jacobowitz a écrit: > >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. > > > > > > Now it looks like this: > > > (gdb) info registers eflags > > > eflags 0x747 [ DF IF TF ZF PF CF ] > > > > > > I've chosen quite a generic way for implementation, so that the others > > > could use this for their types as well. For now I'm using this type > > > only on x86-64, but using it on i386 should be possible without > > > modifications. (BTW Should I do it or the maintainer will?) > > > > > > Any comments? Can I commit? > > > >First of all, please include ChangeLog entries; it makes patches easier > >to digest quickly. > > > >Second, I see that you assume a TYPE_CODE_FLAGS type is the size of a > >long. I'm not fond of 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. > > Beware that if you try to use this in C language, > you will get an error that C language doesn't know anything about TYPE_CODE_SET. > Furthermore, if you force the use of the pascal version of printing sets, > you are still not safe: > Pascal set valprint code does print a set with ranges: > if you have a pascal type > tset = set of [1..16]; > and a variable a of type tset, that contains > 2,5,6,7,8,15 > it will be dispalyed as > [2,5..8,15] > this is also the case for enumerated flags, > but this is bad for the flag enumeration. Sure it is. I'd rather simply fix this for enumerated flags, which it does not make sense to abbreviate in this fashion. > Given this info, I would support the creation of a TYPE_CODE_FLAGS > rather than trying to use pascal sets. > Note that the code submitted does failm to write the flags if language is set to > pascal for instance... So this means that the p-valprint and > maybe others (f-valprint or jv-valprint code should be adapted too). > So maybe the best would be to move thiscode from c-valprint.c to valprint.c > and simply call it for the different language-valprint.c sources. Yes, certainly. Probably even for TYPE_CODE_SET, which I still prefer. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer