From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4814 invoked by alias); 29 Apr 2002 16:54:35 -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 4624 invoked from network); 29 Apr 2002 16:54:32 -0000 Received: from unknown (HELO cerbere.u-strasbg.fr) (130.79.112.7) by sources.redhat.com with SMTP; 29 Apr 2002 16:54:32 -0000 Received: from laocoon (laocoon.u-strasbg.fr [130.79.112.72]) by cerbere.u-strasbg.fr (8.9.3/8.8.7) with ESMTP id SAA10137; Mon, 29 Apr 2002 18:54:18 +0200 Message-Id: <4.2.0.58.20020429180717.020bacb0@ics.u-strasbg.fr> X-Sender: muller@ics.u-strasbg.fr Date: Mon, 29 Apr 2002 09:54:00 -0000 To: Daniel Jacobowitz , Michal Ludvig , gdb-patches@sources.redhat.com From: Pierre Muller Subject: Re: [RFA] New bitflags type and eflags on i386/x86-64 In-Reply-To: <20020422114523.A6524@nevyn.them.org> References: <3CC42916.9080001@suse.cz> <3CC42916.9080001@suse.cz> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-SW-Source: 2002-04/txt/msg01124.txt.bz2 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. 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. Last but not least, adding this patch for i386-tdep source would allow to use this code also for normal i386 cpus. $ cvs diff -u -p i386-tdep.c Index: i386-tdep.c =================================================================== RCS file: /cvs/src/src/gdb/i386-tdep.c,v retrieving revision 1.53 diff -u -p -r1.53 i386-tdep.c --- i386-tdep.c 19 Mar 2002 02:51:07 -0000 1.53 +++ i386-tdep.c 29 Apr 2002 16:51:22 -0000 @@ -1054,6 +1054,9 @@ i386_register_virtual_type (int regnum) if (regnum == PC_REGNUM || regnum == FP_REGNUM || regnum == SP_REGNUM) return lookup_pointer_type (builtin_type_void); + if (regnum == PS_REGNUM) + return builtin_type_i386_eflags; + if (IS_FP_REGNUM (regnum)) return builtin_type_i387_ext; Pierre Muller Institut Charles Sadron 6,rue Boussingault F 67083 STRASBOURG CEDEX (France) mailto:muller@ics.u-strasbg.fr Phone : (33)-3-88-41-40-07 Fax : (33)-3-88-41-40-99