From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24001 invoked by alias); 30 Aug 2002 15:14:45 -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 23985 invoked from network); 30 Aug 2002 15:14:44 -0000 Received: from unknown (HELO cerbere.u-strasbg.fr) (130.79.112.250) by sources.redhat.com with SMTP; 30 Aug 2002 15:14:44 -0000 Received: from laocoon (laocoon.u-strasbg.fr [130.79.112.72]) by cerbere.u-strasbg.fr (Postfix) with ESMTP id 2EAB15F4; Fri, 30 Aug 2002 17:16:29 +0200 (CEST) Message-Id: <4.2.0.58.20020830164921.01c6fba8@ics.u-strasbg.fr> X-Sender: muller@ics.u-strasbg.fr Date: Fri, 30 Aug 2002 10:18:00 -0000 To: Daniel Jacobowitz , Michal Ludvig From: Pierre Muller Subject: Re: [RFA] New bitflags type and eflags on i386/x86-64 Cc: gdb-patches@sources.redhat.com In-Reply-To: <20020830144216.GA13476@nevyn.them.org> References: <3D6F81F5.2040002@suse.cz> <3CC42DA0.9070906@suse.cz> <3D6BF1D5.70409@ges.redhat.com> <3D6E231D.8060906@suse.cz> <20020829142120.GA5176@nevyn.them.org> <3D6E3666.7070309@suse.cz> <20020829150833.GA29973@nevyn.them.org> <3D6E40EE.5000904@ges.redhat.com> <4.2.0.58.20020830155945.00a473b0@ics.u-strasbg.fr> <3D6F81F5.2040002@suse.cz> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-SW-Source: 2002-08/txt/msg01036.txt.bz2 At 16:42 30/08/2002 , Daniel Jacobowitz a écrit: >On Fri, Aug 30, 2002 at 04:32:21PM +0200, Michal Ludvig wrote: > > Pierre Muller wrote: > > > set $eflags &=0xfffe > > >if you wanted to clear the flag at position zero. > > >Will this still be possible without typecasting the flag register ? > > > > Well ... no. But at least > > set (int)$eflags &=0xfffe > > works. That one was finally easy to solve : (I still have the old version of the patch on my computer...) The following patch was enough to get set $eflags &= 0xfffe to work again... it just allows TYPE_CODE_FLAGS to be considered as an integer type for binary operations maybe some other small similar changes are required for unary operations, but it should be easy to solve ! Index: valarith.c =================================================================== RCS file: /cvs/src/src/gdb/valarith.c,v retrieving revision 1.16 diff -u -p -r1.16 valarith.c --- valarith.c 1 Aug 2002 17:18:33 -0000 1.16 +++ valarith.c 30 Aug 2002 15:08:38 -0000 @@ -755,12 +755,14 @@ value_binop (struct value *arg1, struct type2 = check_typedef (VALUE_TYPE (arg2)); if ((TYPE_CODE (type1) != TYPE_CODE_FLT + && TYPE_CODE (type1) != TYPE_CODE_FLAGS && TYPE_CODE (type1) != TYPE_CODE_CHAR && TYPE_CODE (type1) != TYPE_CODE_INT && TYPE_CODE (type1) != TYPE_CODE_BOOL && TYPE_CODE (type1) != TYPE_CODE_RANGE) || (TYPE_CODE (type2) != TYPE_CODE_FLT + && TYPE_CODE (type2) != TYPE_CODE_FLAGS && TYPE_CODE (type2) != TYPE_CODE_CHAR && TYPE_CODE (type2) != TYPE_CODE_INT && TYPE_CODE (type2) != TYPE_CODE_BOOL >You should be able to make the parser promote an lvalue of >TYPE_CODE_FLAGS to TYPE_CODE_INT... The above should be easy to generalize. > > >or willsomething like > > > set $eflags = $eflags | [ZF] > > >be possible ? > > > > I don't know how to do this :-( > >This requires the parser for a given language to support creating >TYPE_CODE_FLAGS. Not necessarily a good idea, our C parser is >delicate enough already. I completely agree that it a bad idea, mainly because it would add some new names that could conflict with program variables... But I think that getting TYPE_CODE_FLAGS to be aconsidered as an integer type for all but display should not be so hard, and this will remove a potential source of future bug reports about : I can manipulate the $eflags register anymore or: My ten years old GDB script issues an error in GDB 5.3 ... >-- >Daniel Jacobowitz >MontaVista Software Debian GNU/Linux Developer 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