Re: [RFA] New bitflags type and eflags on i386/x86-64

[Pierre Muller <muller@ics.u-strasbg.fr>]

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