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

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

[Michal Ludvig]

[-- Attachment #1: Type: text/plain, Size: 772 bytes --]

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?

Michal Ludvig
-- 
* SuSE CR, s.r.o     * mludvig@suse.cz
* +420 2 9654 5373   * http://www.suse.cz

[-- Attachment #2: eflags.diff --]
[-- Type: text/plain, Size: 8136 bytes --]

Index: c-valprint.c
===================================================================
RCS file: /cvs/src/src/gdb/c-valprint.c,v
retrieving revision 1.13
diff -u -r1.13 c-valprint.c
--- c-valprint.c	5 Feb 2002 21:41:29 -0000	1.13
+++ c-valprint.c	22 Apr 2002 14:50:12 -0000
@@ -70,6 +70,7 @@
 	     int deref_ref, int recurse, enum val_prettyprint pretty)
 {
   register unsigned int i = 0;	/* Number of characters printed */
+  register int j;
   unsigned len;
   struct type *elttype;
   unsigned eltlen;
@@ -483,6 +484,30 @@
 			TYPE_TARGET_TYPE (type),
 			stream);
       fprintf_filtered (stream, " * I");
+      break;
+
+    case TYPE_CODE_FLAGS:
+      if (format)
+	{
+	  print_scalar_formatted (valaddr + embedded_offset, type, format, 0, stream);
+	  break;
+	}
+      len = TYPE_NFIELDS (type);
+      val = unpack_long (type, valaddr + embedded_offset);
+      fputs_filtered("[", stream);
+      for (j = len-1; j >= 0; j--)
+	{
+	  QUIT;
+	  if (TYPE_FIELD_BITPOS (type, j) != -1 && val & (1 << j))
+	  {
+		  if(TYPE_FIELD_NAME (type, j))
+			  fprintf_filtered (stream, " %s", TYPE_FIELD_NAME (type, j));
+		  else
+			  fprintf_filtered (stream, " #%d", j);
+				  
+	  }
+	}
+      fputs_filtered(" ]", stream);
       break;
 
     default:
Index: gdbtypes.c
===================================================================
RCS file: /cvs/src/src/gdb/gdbtypes.c,v
retrieving revision 1.43
diff -u -r1.43 gdbtypes.c
--- gdbtypes.c	20 Apr 2002 01:09:28 -0000	1.43
+++ gdbtypes.c	22 Apr 2002 14:50:13 -0000
@@ -99,6 +99,7 @@
 struct type *builtin_type_void_func_ptr;
 struct type *builtin_type_CORE_ADDR;
 struct type *builtin_type_bfd_vma;
+struct type *builtin_type_i386_eflags;
 
 int opaque_type_resolution = 1;
 int overload_debug = 0;
@@ -777,6 +778,67 @@
   return (result_type);
 }
 
+/*
+ * - The following three functions are intended to be used for BitFlags 
+ *   types (ie i386's EFLAGS register).
+ * - As a BitFlag we understand an integer where some bits may have 
+ *   a symbolic names that would be printed when the bit is set.
+ * - Printing is done in c_val_print() under a TYPE_CODE_FLAGS label.
+ * - All bits are set to be ignored (ie. not printed even when set) 
+ *   by default.
+ * - Add a symbolic name of relevant bits using add_flag_name() after 
+ *   an initialisation of your type.
+ */
+void
+add_flag_ignore (struct type *type, int bitpos)
+{
+	TYPE_FIELD_BITPOS (type, bitpos) = -1;
+}
+
+void
+add_flag_name (struct type *type, int bitpos, char *name)
+{
+	int namelen;
+	
+	gdb_assert (TYPE_CODE (type) == TYPE_CODE_FLAGS);
+	gdb_assert (bitpos < TYPE_NFIELDS (type));
+	gdb_assert (bitpos >= 0);
+	
+	namelen=strlen(name)+1;
+	TYPE_FIELD_NAME (type, bitpos) = xmalloc (namelen);
+	snprintf(TYPE_FIELD_NAME (type, bitpos), namelen, "%s", name);	
+
+	TYPE_FIELD_BITPOS (type, bitpos) = bitpos;
+}
+
+struct type *
+init_flags_type (int bitlength, char *name, struct objfile *objfile)
+{
+  register struct type *type;
+  int i;
+  
+  type = alloc_type (objfile);
+  
+  TYPE_CODE (type) = TYPE_CODE_FLAGS;
+  TYPE_LENGTH (type) = bitlength / 8 + ( bitlength % 8 ? 1 : 0 );
+  TYPE_FLAGS (type) = TYPE_FLAG_UNSIGNED;
+  TYPE_NFIELDS (type) = bitlength;
+  TYPE_FIELDS (type) = (struct field *)
+    TYPE_ALLOC (type, bitlength * sizeof (struct field));
+  memset (TYPE_FIELDS (type), 0, sizeof (struct field));
+
+  if ((name != NULL) && (objfile != NULL))
+      TYPE_NAME (type) =
+	obsavestring (name, strlen (name), &objfile->type_obstack);
+  else
+      TYPE_NAME (type) = name;
+  
+  for(i=0; i<bitlength; i++)
+	add_flag_ignore (type, i);
+
+  return (type);
+}
+
 /* Construct and return a type of the form:
 	struct NAME { ELT_TYPE ELT_NAME[N]; }
    We use these types for SIMD registers.  For example, the type of
@@ -1841,6 +1903,7 @@
   return
     ((t != NULL)
      && ((TYPE_CODE (t) == TYPE_CODE_INT)
+	 || (TYPE_CODE (t) == TYPE_CODE_FLAGS)
 	 || (TYPE_CODE (t) == TYPE_CODE_ENUM)
 	 || (TYPE_CODE (t) == TYPE_CODE_CHAR)
 	 || (TYPE_CODE (t) == TYPE_CODE_RANGE)
@@ -2372,6 +2435,7 @@
 	case TYPE_CODE_FUNC:
 	  return rank_one_type (TYPE_TARGET_TYPE (parm), arg);
 	case TYPE_CODE_INT:
+	case TYPE_CODE_FLAGS:
 	case TYPE_CODE_ENUM:
 	case TYPE_CODE_CHAR:
 	case TYPE_CODE_RANGE:
@@ -2448,6 +2512,8 @@
 	    return INTEGER_PROMOTION_BADNESS;
 	  else
 	    return INTEGER_COERCION_BADNESS;
+        case TYPE_CODE_FLAGS:
+	  return 0;
 	case TYPE_CODE_ENUM:
 	case TYPE_CODE_CHAR:
 	case TYPE_CODE_RANGE:
@@ -2898,6 +2964,9 @@
     case TYPE_CODE_INT:
       printf_filtered ("(TYPE_CODE_INT)");
       break;
+    case TYPE_CODE_FLAGS:
+      printf_filtered ("(TYPE_CODE_FLAGS)");
+      break;
     case TYPE_CODE_FLT:
       printf_filtered ("(TYPE_CODE_FLT)");
       break;
@@ -3318,6 +3387,28 @@
     init_type (TYPE_CODE_INT, TARGET_BFD_VMA_BIT / 8,
 	       TYPE_FLAG_UNSIGNED,
 	       "__bfd_vma", (struct objfile *) NULL);
+  builtin_type_i386_eflags = 
+    init_flags_type (32 /* EFLAGS_LENGTH */, 
+    	       "__i386_eflags", (struct objfile *) NULL);
+  add_flag_name (builtin_type_i386_eflags, 0, "CF");
+  add_flag_ignore (builtin_type_i386_eflags, 1);
+  add_flag_name (builtin_type_i386_eflags, 2, "PF");
+  add_flag_name (builtin_type_i386_eflags, 4, "AF");
+  add_flag_name (builtin_type_i386_eflags, 6, "ZF");
+  add_flag_name (builtin_type_i386_eflags, 7, "SF");
+  add_flag_name (builtin_type_i386_eflags, 8, "TF");
+  add_flag_name (builtin_type_i386_eflags, 9, "IF");
+  add_flag_name (builtin_type_i386_eflags, 10, "DF");
+  add_flag_name (builtin_type_i386_eflags, 11, "OF");
+  add_flag_ignore (builtin_type_i386_eflags, 12);
+  add_flag_ignore (builtin_type_i386_eflags, 13);
+  add_flag_name (builtin_type_i386_eflags, 14, "NT");
+  add_flag_name (builtin_type_i386_eflags, 16, "RF");
+  add_flag_name (builtin_type_i386_eflags, 17, "VM");
+  add_flag_name (builtin_type_i386_eflags, 18, "AC");
+  add_flag_name (builtin_type_i386_eflags, 19, "VIF");
+  add_flag_name (builtin_type_i386_eflags, 20, "VIP");
+  add_flag_name (builtin_type_i386_eflags, 21, "ID");
 }
 
 
Index: gdbtypes.h
===================================================================
RCS file: /cvs/src/src/gdb/gdbtypes.h,v
retrieving revision 1.27
diff -u -r1.27 gdbtypes.h
--- gdbtypes.h	23 Mar 2002 01:24:54 -0000	1.27
+++ gdbtypes.h	22 Apr 2002 14:50:13 -0000
@@ -85,6 +85,7 @@
     TYPE_CODE_ENUM,		/* Enumeration type */
     TYPE_CODE_FUNC,		/* Function type */
     TYPE_CODE_INT,		/* Integer type */
+    TYPE_CODE_FLAGS,		/* BitFlags type */
 
     /* Floating type.  This is *NOT* a complex type.  Beware, there are parts
        of GDB which bogusly assume that TYPE_CODE_FLT can mean complex.  */
@@ -930,6 +931,10 @@
 
 /* The target CPU's address type.  This is the ISA address size. */
 extern struct type *builtin_type_CORE_ADDR;
+
+/* Type for i386 EFLAGS register.  */
+extern struct type *builtin_type_i386_eflags;
+
 /* The symbol table address type.  Some object file formats have a 32
    bit address type even though the TARGET has a 64 bit pointer type
    (cf MIPS). */
Index: values.c
===================================================================
RCS file: /cvs/src/src/gdb/values.c,v
retrieving revision 1.34
diff -u -r1.34 values.c
--- values.c	29 Jan 2002 03:08:26 -0000	1.34
+++ values.c	22 Apr 2002 14:50:14 -0000
@@ -697,6 +697,7 @@
     case TYPE_CODE_ENUM:
     case TYPE_CODE_BOOL:
     case TYPE_CODE_INT:
+    case TYPE_CODE_FLAGS:
     case TYPE_CODE_CHAR:
     case TYPE_CODE_RANGE:
       if (nosign)
Index: x86-64-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/x86-64-tdep.c,v
retrieving revision 1.13
diff -u -r1.13 x86-64-tdep.c
--- x86-64-tdep.c	6 Apr 2002 00:02:50 -0000	1.13
+++ x86-64-tdep.c	22 Apr 2002 14:50:22 -0000
@@ -66,7 +66,7 @@
   {8, "r14", &builtin_type_int64},
   {8, "r15", &builtin_type_int64},
   {8, "rip", &builtin_type_void_func_ptr},
-  {4, "eflags", &builtin_type_int32},
+  {4, "eflags", &builtin_type_i386_eflags},
   {4, "ds", &builtin_type_int32},
   {4, "es", &builtin_type_int32},
   {4, "fs", &builtin_type_int32},

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

[Daniel Jacobowitz]

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.


-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

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

[Michal Ludvig]

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'...

> 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...

Michal Ludvig
-- 
* SuSE CR, s.r.o     * mludvig@suse.cz
* +420 2 9654 5373   * http://www.suse.cz

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

[Andrew Cagney]

> 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'...

Yep, LONGEST is the bigest int.  DOUBLEST the biggest float.

Andrew

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

[Daniel Jacobowitz]

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

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

[Michal Ludvig]

Daniel Jacobowitz wrote:
> On Mon, Apr 22, 2002 at 06:08:09PM +0200, Michal Ludvig wrote:
> 
>>Daniel Jacobowitz wrote:
> unpack_long returns LONGEST.  Why not have a flagword bigger than that?

Where would you store it? And what type would you use for it?

>>>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 still don't understand these "nested" types :-(

Is this a correct procedure?
- create an ENUM type
- set its nfields to number of bits of my flagword.
- allocate space for its fields[bits] and fill all fields with propper
   position of the bit and its name.
- call create_set_type with the just created enum

Is that all?

Than I have some questions:
- What should be in the 'length' field of ENUM and what in lenght field 
of SET?
- Should I set ENUM's entries (fields) for all bits in the flagword (eg. 
32) or is it enough to set only used ones and ignore the rest when 
printing it (I'd prefer this approach).

BTW How do I extract a value of the variable using unpack_long()? I 
tried to call it both with type and elttype but always got a wrong 
result. Can it be because of wrong lenght fields in these types?

>>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.

Actually, I do. Type FLAG perfectly and cleanly does what it was ceated 
for and is self-describing. Using SET seems to be less synoptical. Also 
SET is used so rarely in gdb that it isn't a defact standard for such 
things.

Michal Ludvig
-- 
* SuSE CR, s.r.o     * mludvig@suse.cz
* +420 2 9654 5373   * http://www.suse.cz

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

[Daniel Jacobowitz]

On Tue, Apr 23, 2002 at 03:22:01PM +0200, Michal Ludvig wrote:
> Daniel Jacobowitz wrote:
> >On Mon, Apr 22, 2002 at 06:08:09PM +0200, Michal Ludvig wrote:
> >
> >>Daniel Jacobowitz wrote:
> >unpack_long returns LONGEST.  Why not have a flagword bigger than that?
> 
> Where would you store it? And what type would you use for it?

In memory, of course, and TYPE_CODE_SET :)

> >>>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 still don't understand these "nested" types :-(
> 
> Is this a correct procedure?
> - create an ENUM type
> - set its nfields to number of bits of my flagword.
> - allocate space for its fields[bits] and fill all fields with propper
>   position of the bit and its name.
> - call create_set_type with the just created enum
> 
> Is that all?

I haven't tried it.  That looks right to me, though.

> Than I have some questions:
> - What should be in the 'length' field of ENUM and what in lenght field 
> of SET?

Doesn't matter (probably 0) and set by create_set_type, respectively.

> - Should I set ENUM's entries (fields) for all bits in the flagword (eg. 
> 32) or is it enough to set only used ones and ignore the rest when 
> printing it (I'd prefer this approach).

Well, up to you.

It occurs to me - there is a disadvantage of using types.  Will they be
printed according to the "current" language?  What happens with your
TYPE_CODE_FLAGS patch if you 'set language pascal' before 'info
registers'?

Should we always print registers as C types?

> BTW How do I extract a value of the variable using unpack_long()? I 
> tried to call it both with type and elttype but always got a wrong 
> result. Can it be because of wrong lenght fields in these types?

No idea.

> 
> >>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.
> 
> Actually, I do. Type FLAG perfectly and cleanly does what it was ceated 
> for and is self-describing. Using SET seems to be less synoptical. Also 
> SET is used so rarely in gdb that it isn't a defact standard for such 
> things.

But it serves the precise same purpose and already exists!

I don't really care, though (and can't approve things in this area
anyway).  You might want to get a comment from someone who can before
you go further.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

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

[Pierre Muller]

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

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

[Michal Ludvig]

Pierre Muller wrote:
> 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.

Thanks for comments. I'll rework the patch and send again for approval 
with these changes. I was never a fan of "raping" type SET for this 
purpose.

> Last but not least, adding this  patch for i386-tdep source would allow to use
> this code also for normal  i386 cpus.

Sure, this bit is easy.

Michal Ludvig
-- 
* SuSE CR, s.r.o     * mludvig@suse.cz
* +420 2 9654 5373   * http://www.suse.cz

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

[Daniel Jacobowitz]

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

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

[Andrew Cagney]

>    Date: Thu, 05 Sep 2002 10:04:11 +0200
>    From: Michal Ludvig <mludvig@suse.cz>
> 
>    Daniel Jacobowitz wrote:
>    > On Tue, Sep 03, 2002 at 11:17:43AM +0200, Michal Ludvig wrote:
>    >>Thanks for help. Attached file incorporates your patch as well. Could 
>    >>anyone approve it, please?
>    > 
>    > Can't approve it, but I like it.  Thanks for following this through.
> 
>    Who can approve? Andrew? MarkK? Someone else?
> 
> Well, I'm not too happy about the introduction of i386-common-tdep.c.
> I mean, those functions belong in i386-tdep.c.  Can we postpone
> integrating this patch until I've unified the i386 and x86-64 targets
> into one truly multi-arched one?  I've started working on that now,
> honestly :-).
> 
> Anyway, before approving this I'd like to see a bit more consensus
> about the BitFlags type your patch introduces.  Andrew, is it OK with
> you now?

Daniel was the one with concerns, I believe they were addressed.

Michael, what does a user interaction where values are set/cleared look 
like?  It should be pretty obvious without needing to look at a manual.

Andrew


> There also some coding-style problems with your code:
> 
> Index: gdbtypes.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/gdbtypes.c,v
> retrieving revision 1.56
> diff -u -p -r1.56 gdbtypes.c
> --- gdbtypes.c	20 Aug 2002 19:57:32 -0000	1.56
> +++ gdbtypes.c	30 Aug 2002 13:42:50 -0000
> @@ -782,6 +782,61 @@ create_set_type (struct type *result_typ
>    return (result_type);
>  }
>  
> +/*
> + * - The following three functions are intended to be used for BitFlags 
> + *   types (e.g. i386's EFLAGS register).
> + * - A BitFlags type is an integer where bits may have a symbolic name 
> + *   to be printed when the bit is set.
> + * - Printing is done in <lang>_val_print() under a TYPE_CODE_FLAGS label.
> + * - Add symbolic names for relevant bits using add_flag_name() after
> + *   initializing the BitFlags type.
> + */
> 
> That's not the right comment style.
> 
> +void
> +add_flag_ignore (struct type *type, int bitpos)
> +{
> +	TYPE_FIELD_BITPOS (type, bitpos) = -1;
> +}
> 
> Indentation is wrong here...
> 
> +void
> +add_flag_name (struct type *type, int bitpos, char *name)
> +{
> +	int namelen;
> +	
> +	gdb_assert (TYPE_CODE (type) == TYPE_CODE_FLAGS);
> +	gdb_assert (bitpos < TYPE_NFIELDS (type));
> +	gdb_assert (bitpos >= 0);
> +	
> +	namelen=strlen(name)+1;
> +	TYPE_FIELD_NAME (type, bitpos) = xmalloc (namelen);
> +	snprintf(TYPE_FIELD_NAME (type, bitpos), namelen, "%s", name);	
> +
> +	TYPE_FIELD_BITPOS (type, bitpos) = bitpos;
> +}
> 
> ...and here.
> 
> +struct type *
> +init_flags_type (int bitlength, char *name, struct objfile *objfile)
> +{
> +  register struct type *type;
> 
> We're trying to get rid of "register".
> 
> Index: gdbtypes.h
> ===================================================================
> RCS file: /cvs/src/src/gdb/gdbtypes.h,v
> retrieving revision 1.35
> diff -u -p -r1.35 gdbtypes.h
> --- gdbtypes.h	10 Aug 2002 05:12:40 -0000	1.35
> +++ gdbtypes.h	30 Aug 2002 13:42:51 -0000
> @@ -1054,6 +1056,14 @@ extern struct type *alloc_type (struct o
>  
>  extern struct type *init_type (enum type_code, int, int, char *,
>  			       struct objfile *);
> +
> +/* Helper functions to construct BitField type.  
> +   See description in gdbarch.c for details.  */
> 
> Are you sure this reference to gdbarch.c is still correct?
> 
> Mark
> 

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

[Mark Kettenis]

   Date: Thu, 05 Sep 2002 10:04:11 +0200
   From: Michal Ludvig <mludvig@suse.cz>

   Daniel Jacobowitz wrote:
   > On Tue, Sep 03, 2002 at 11:17:43AM +0200, Michal Ludvig wrote:
   >>Thanks for help. Attached file incorporates your patch as well. Could 
   >>anyone approve it, please?
   > 
   > Can't approve it, but I like it.  Thanks for following this through.

   Who can approve? Andrew? MarkK? Someone else?

Well, I'm not too happy about the introduction of i386-common-tdep.c.
I mean, those functions belong in i386-tdep.c.  Can we postpone
integrating this patch until I've unified the i386 and x86-64 targets
into one truly multi-arched one?  I've started working on that now,
honestly :-).

Anyway, before approving this I'd like to see a bit more consensus
about the BitFlags type your patch introduces.  Andrew, is it OK with
you now?

There also some coding-style problems with your code:

Index: gdbtypes.c
===================================================================
RCS file: /cvs/src/src/gdb/gdbtypes.c,v
retrieving revision 1.56
diff -u -p -r1.56 gdbtypes.c
--- gdbtypes.c	20 Aug 2002 19:57:32 -0000	1.56
+++ gdbtypes.c	30 Aug 2002 13:42:50 -0000
@@ -782,6 +782,61 @@ create_set_type (struct type *result_typ
   return (result_type);
 }
 
+/*
+ * - The following three functions are intended to be used for BitFlags 
+ *   types (e.g. i386's EFLAGS register).
+ * - A BitFlags type is an integer where bits may have a symbolic name 
+ *   to be printed when the bit is set.
+ * - Printing is done in <lang>_val_print() under a TYPE_CODE_FLAGS label.
+ * - Add symbolic names for relevant bits using add_flag_name() after
+ *   initializing the BitFlags type.
+ */

That's not the right comment style.

+void
+add_flag_ignore (struct type *type, int bitpos)
+{
+	TYPE_FIELD_BITPOS (type, bitpos) = -1;
+}

Indentation is wrong here...

+void
+add_flag_name (struct type *type, int bitpos, char *name)
+{
+	int namelen;
+	
+	gdb_assert (TYPE_CODE (type) == TYPE_CODE_FLAGS);
+	gdb_assert (bitpos < TYPE_NFIELDS (type));
+	gdb_assert (bitpos >= 0);
+	
+	namelen=strlen(name)+1;
+	TYPE_FIELD_NAME (type, bitpos) = xmalloc (namelen);
+	snprintf(TYPE_FIELD_NAME (type, bitpos), namelen, "%s", name);	
+
+	TYPE_FIELD_BITPOS (type, bitpos) = bitpos;
+}

...and here.

+struct type *
+init_flags_type (int bitlength, char *name, struct objfile *objfile)
+{
+  register struct type *type;

We're trying to get rid of "register".

Index: gdbtypes.h
===================================================================
RCS file: /cvs/src/src/gdb/gdbtypes.h,v
retrieving revision 1.35
diff -u -p -r1.35 gdbtypes.h
--- gdbtypes.h	10 Aug 2002 05:12:40 -0000	1.35
+++ gdbtypes.h	30 Aug 2002 13:42:51 -0000
@@ -1054,6 +1056,14 @@ extern struct type *alloc_type (struct o
 
 extern struct type *init_type (enum type_code, int, int, char *,
 			       struct objfile *);
+
+/* Helper functions to construct BitField type.  
+   See description in gdbarch.c for details.  */

Are you sure this reference to gdbarch.c is still correct?

Mark

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

[Michal Ludvig]

Daniel Jacobowitz wrote:
> On Tue, Sep 03, 2002 at 11:17:43AM +0200, Michal Ludvig wrote:
>>Thanks for help. Attached file incorporates your patch as well. Could 
>>anyone approve it, please?
> 
> Can't approve it, but I like it.  Thanks for following this through.

Who can approve? Andrew? MarkK? Someone else?

Michal Ludvig
-- 
* SuSE CR, s.r.o     * mludvig@suse.cz
* +420 2 9654 5373   * http://www.suse.cz

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

[Daniel Jacobowitz]

On Tue, Sep 03, 2002 at 11:17:43AM +0200, Michal Ludvig wrote:
> Pierre Muller wrote:
> >>>set (int)$eflags &=0xfffe
> >
> >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 !
> 
> Thanks for help. Attached file incorporates your patch as well. Could 
> anyone approve it, please?

Can't approve it, but I like it.  Thanks for following this through.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

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

[Michal Ludvig]

[-- Attachment #1: Type: text/plain, Size: 640 bytes --]

Pierre Muller wrote:
>>>set (int)$eflags &=0xfffe
> 
> 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 !

Thanks for help. Attached file incorporates your patch as well. Could 
anyone approve it, please?

Michal Ludvig
-- 
* SuSE CR, s.r.o     * mludvig@suse.cz
* +420 2 9654 5373   * http://www.suse.cz

[-- Attachment #2: flags-7.diff --]
[-- Type: text/plain, Size: 35963 bytes --]

2002-08-29  Michal Ludvig  <mludvig@suse.cz>

	* gdbtypes.c 	(add_flag_ignore, add_flag_name, init_flags_type): Added.
	(is_integral_type, rank_one_type, recursive_dump_type): Added
	TYPE_CODE_FLAGS handling.
	* gdbtypes.h (type_code): Added TYPE_CODE_FLAGS.
	* valprint.c (val_print_type_code_flags): Added.
	* valprint.h (val_print_type_code_flags): Added.
	* valarith.c (value_binop): Added TYPE_CODE_FLAGS handling.
	* values.c (unpack_long): Ditto.
	* i386-common-tdep.o: New file.
	(builtin_type_i386_eflags): Added.
	(builtin_type_simd_mxcsr): Added.
	(_initialize_i386_common_tdep): Perform builtin_type_i386_eflags 
	and builtin_type_simd_mxcsr initialization.
	* i386-common-tdep.h: New file.
	(builtin_type_i386_eflags): Added.
	(builtin_type_simd_mxcsr): Added.
	* i386-tdep.c (i386_register_virtual_type): Added eflags and 
	mxcsr registers handling.
	* x86-64-tdep.c (x86_64_register_info_table): Changed type 
	of eflags and mxcsr registers.
	* ada-valprint.c (ada_val_print_1): Added TYPE_CODE_FLAGS case.
	* c-valprint.c (c_val_print): Ditto.
	* f-valprint.c (f_val_print): Ditto.
	* jv-valprint.c (java_val_print): Ditto.
	* p-valprint.c (pascal_val_print): Ditto.
	* config/i386/x86-64linux.mt: Added i386-common-tdep.o
	* config/i386/i386aix.mt: Ditto.
	* config/i386/i386aout.mt: Ditto.
	* config/i386/i386bsd.mt: Ditto.
	* config/i386/i386gnu.mt: Ditto.
	* config/i386/i386lynx.mt: Ditto.
	* config/i386/i386m3.mt: Ditto.
	* config/i386/i386mk.mt: Ditto.
	* config/i386/i386nw.mt: Ditto.
	* config/i386/i386os9k.mt: Ditto.
	* config/i386/i386sco5.mt: Ditto.
	* config/i386/i386sol2.mt: Ditto.
	* config/i386/i386v.mt: Ditto.
	* config/i386/i386v4.mt: Ditto.
	* config/i386/i386v42mp.mt: Ditto.
	* config/i386/linux.mt: Ditto.
	* config/i386/cygwin.mt: Ditto.
	* config/i386/embed.mt: Ditto.
	* config/i386/fbsd.mt: Ditto.
	* config/i386/go32.mt: Ditto.
	* config/i386/nbsdaout.mt: Ditto.
	* config/i386/nbsdelf.mt: Ditto.
	* config/i386/ncr3000.mt: Ditto.
	* config/i386/ptx.mt: Ditto.
	* config/i386/ptx4.mt: Ditto.
	* config/i386/symmetry.mt: Ditto.
	* config/i386/vxworks.mt: Ditto.

Index: gdbtypes.c
===================================================================
RCS file: /cvs/src/src/gdb/gdbtypes.c,v
retrieving revision 1.56
diff -u -p -r1.56 gdbtypes.c
--- gdbtypes.c	20 Aug 2002 19:57:32 -0000	1.56
+++ gdbtypes.c	30 Aug 2002 13:42:50 -0000
@@ -782,6 +782,61 @@ create_set_type (struct type *result_typ
   return (result_type);
 }
 
+/*
+ * - The following three functions are intended to be used for BitFlags 
+ *   types (e.g. i386's EFLAGS register).
+ * - A BitFlags type is an integer where bits may have a symbolic name 
+ *   to be printed when the bit is set.
+ * - Printing is done in <lang>_val_print() under a TYPE_CODE_FLAGS label.
+ * - Add symbolic names for relevant bits using add_flag_name() after
+ *   initializing the BitFlags type.
+ */
+void
+add_flag_ignore (struct type *type, int bitpos)
+{
+	TYPE_FIELD_BITPOS (type, bitpos) = -1;
+}
+
+void
+add_flag_name (struct type *type, int bitpos, char *name)
+{
+	int namelen;
+	
+	gdb_assert (TYPE_CODE (type) == TYPE_CODE_FLAGS);
+	gdb_assert (bitpos < TYPE_NFIELDS (type));
+	gdb_assert (bitpos >= 0);
+	
+	namelen=strlen(name)+1;
+	TYPE_FIELD_NAME (type, bitpos) = xmalloc (namelen);
+	snprintf(TYPE_FIELD_NAME (type, bitpos), namelen, "%s", name);	
+
+	TYPE_FIELD_BITPOS (type, bitpos) = bitpos;
+}
+
+struct type *
+init_flags_type (int bitlength, char *name, struct objfile *objfile)
+{
+  register struct type *type;
+  
+  type = alloc_type (objfile);
+  
+  TYPE_CODE (type) = TYPE_CODE_FLAGS;
+  TYPE_LENGTH (type) = (bitlength + TARGET_CHAR_BIT - 1) / TARGET_CHAR_BIT;
+  TYPE_FLAGS (type) = TYPE_FLAG_UNSIGNED;
+  TYPE_NFIELDS (type) = bitlength;
+  TYPE_FIELDS (type) = (struct field *)
+    TYPE_ALLOC (type, bitlength * sizeof (struct field));
+  memset (TYPE_FIELDS (type), 0, sizeof (struct field));
+
+  if ((name != NULL) && (objfile != NULL))
+      TYPE_NAME (type) =
+	obsavestring (name, strlen (name), &objfile->type_obstack);
+  else
+      TYPE_NAME (type) = name;
+  
+  return (type);
+}
+
 /* Construct and return a type of the form:
 	struct NAME { ELT_TYPE ELT_NAME[N]; }
    We use these types for SIMD registers.  For example, the type of
@@ -1946,6 +2001,7 @@ is_integral_type (struct type *t)
   return
     ((t != NULL)
      && ((TYPE_CODE (t) == TYPE_CODE_INT)
+	 || (TYPE_CODE (t) == TYPE_CODE_FLAGS)
 	 || (TYPE_CODE (t) == TYPE_CODE_ENUM)
 	 || (TYPE_CODE (t) == TYPE_CODE_CHAR)
 	 || (TYPE_CODE (t) == TYPE_CODE_RANGE)
@@ -2479,6 +2535,7 @@ rank_one_type (struct type *parm, struct
 	case TYPE_CODE_FUNC:
 	  return rank_one_type (TYPE_TARGET_TYPE (parm), arg);
 	case TYPE_CODE_INT:
+	case TYPE_CODE_FLAGS:
 	case TYPE_CODE_ENUM:
 	case TYPE_CODE_CHAR:
 	case TYPE_CODE_RANGE:
@@ -2555,6 +2612,7 @@ rank_one_type (struct type *parm, struct
 	    return INTEGER_PROMOTION_BADNESS;
 	  else
 	    return INTEGER_COERCION_BADNESS;
+        case TYPE_CODE_FLAGS:
 	case TYPE_CODE_ENUM:
 	case TYPE_CODE_CHAR:
 	case TYPE_CODE_RANGE:
@@ -2999,6 +3057,9 @@ recursive_dump_type (struct type *type, 
       break;
     case TYPE_CODE_INT:
       printf_filtered ("(TYPE_CODE_INT)");
+      break;
+    case TYPE_CODE_FLAGS:
+      printf_filtered ("(TYPE_CODE_FLAGS)");
       break;
     case TYPE_CODE_FLT:
       printf_filtered ("(TYPE_CODE_FLT)");
Index: gdbtypes.h
===================================================================
RCS file: /cvs/src/src/gdb/gdbtypes.h,v
retrieving revision 1.35
diff -u -p -r1.35 gdbtypes.h
--- gdbtypes.h	10 Aug 2002 05:12:40 -0000	1.35
+++ gdbtypes.h	30 Aug 2002 13:42:51 -0000
@@ -85,6 +85,7 @@ enum type_code
     TYPE_CODE_ENUM,		/* Enumeration type */
     TYPE_CODE_FUNC,		/* Function type */
     TYPE_CODE_INT,		/* Integer type */
+    TYPE_CODE_FLAGS,		/* BitFlags type */
 
     /* Floating type.  This is *NOT* a complex type.  Beware, there are parts
        of GDB which bogusly assume that TYPE_CODE_FLT can mean complex.  */
@@ -926,6 +927,7 @@ extern struct type *builtin_type_void_fu
 
 /* The target CPU's address type.  This is the ISA address size. */
 extern struct type *builtin_type_CORE_ADDR;
+
 /* The symbol table address type.  Some object file formats have a 32
    bit address type even though the TARGET has a 64 bit pointer type
    (cf MIPS). */
@@ -1054,6 +1056,14 @@ extern struct type *alloc_type (struct o
 
 extern struct type *init_type (enum type_code, int, int, char *,
 			       struct objfile *);
+
+/* Helper functions to construct BitField type.  
+   See description in gdbarch.c for details.  */
+
+struct type *init_flags_type (int bitlength, char *name, 
+		              struct objfile *objfile);
+void add_flag_ignore (struct type *type, int bitpos);
+void add_flag_name (struct type *type, int bitpos, char *name);
 
 /* Helper functions to construct a struct or record type.  An
    initially empty type is created using init_composite_type().
Index: i386-common-tdep.c
===================================================================
RCS file: i386-common-tdep.c
diff -N i386-common-tdep.c
--- /dev/null	1 Jan 1970 00:00:00 -0000
+++ i386-common-tdep.c	30 Aug 2002 13:42:51 -0000
@@ -0,0 +1,75 @@
+/* Target-dependent code common for both i386 and x86-64 archs.
+
+   Copyright 2002 Free Software Foundation, Inc.
+
+   Contributed by Michal Ludvig, SuSE Labs.
+
+   This file is part of GDB.
+
+   This program is free software; you can redistribute it and/or modify
+   it under the terms of the GNU General Public License as published by
+   the Free Software Foundation; either version 2 of the License, or
+   (at your option) any later version.
+
+   This program is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+   GNU General Public License for more details.
+
+   You should have received a copy of the GNU General Public License
+   along with this program; if not, write to the Free Software
+   Foundation, Inc., 59 Temple Place - Suite 330,
+   Boston, MA 02111-1307, USA.  */
+
+#include "defs.h"
+#include "gdbtypes.h"
+
+struct type *builtin_type_i386_eflags;
+struct type *builtin_type_simd_mxcsr;
+
+void
+_initialize_i386_common_tdep (void)
+{
+  builtin_type_i386_eflags = 
+    init_flags_type (32 /* EFLAGS_LENGTH */, 
+    	       "__i386_eflags", (struct objfile *) NULL);
+  add_flag_name (builtin_type_i386_eflags, 0, "CF");
+  add_flag_ignore (builtin_type_i386_eflags, 1);
+  add_flag_name (builtin_type_i386_eflags, 2, "PF");
+  add_flag_name (builtin_type_i386_eflags, 4, "AF");
+  add_flag_name (builtin_type_i386_eflags, 6, "ZF");
+  add_flag_name (builtin_type_i386_eflags, 7, "SF");
+  add_flag_name (builtin_type_i386_eflags, 8, "TF");
+  add_flag_name (builtin_type_i386_eflags, 9, "IF");
+  add_flag_name (builtin_type_i386_eflags, 10, "DF");
+  add_flag_name (builtin_type_i386_eflags, 11, "OF");
+  add_flag_ignore (builtin_type_i386_eflags, 12);
+  add_flag_ignore (builtin_type_i386_eflags, 13);
+  add_flag_name (builtin_type_i386_eflags, 14, "NT");
+  add_flag_name (builtin_type_i386_eflags, 16, "RF");
+  add_flag_name (builtin_type_i386_eflags, 17, "VM");
+  add_flag_name (builtin_type_i386_eflags, 18, "AC");
+  add_flag_name (builtin_type_i386_eflags, 19, "VIF");
+  add_flag_name (builtin_type_i386_eflags, 20, "VIP");
+  add_flag_name (builtin_type_i386_eflags, 21, "ID");
+  
+  builtin_type_simd_mxcsr = 
+    init_flags_type (32 /* MXCSR_LENGTH */, 
+    	       "__simd_mxcsr", (struct objfile *) NULL);
+  add_flag_name (builtin_type_simd_mxcsr, 0, "IE");
+  add_flag_name (builtin_type_simd_mxcsr, 1, "DE");
+  add_flag_name (builtin_type_simd_mxcsr, 2, "ZE");
+  add_flag_name (builtin_type_simd_mxcsr, 3, "OE");
+  add_flag_name (builtin_type_simd_mxcsr, 4, "UE");
+  add_flag_name (builtin_type_simd_mxcsr, 5, "PE");
+  add_flag_name (builtin_type_simd_mxcsr, 6, "DAZ");
+  add_flag_name (builtin_type_simd_mxcsr, 7, "IM");
+  add_flag_name (builtin_type_simd_mxcsr, 8, "DM");
+  add_flag_name (builtin_type_simd_mxcsr, 9, "ZM");
+  add_flag_name (builtin_type_simd_mxcsr, 10, "OM");
+  add_flag_name (builtin_type_simd_mxcsr, 11, "UM");
+  add_flag_name (builtin_type_simd_mxcsr, 12, "PM");
+  add_flag_name (builtin_type_simd_mxcsr, 13, "RC1");
+  add_flag_name (builtin_type_simd_mxcsr, 14, "RC2");
+  add_flag_name (builtin_type_simd_mxcsr, 15, "FZ");
+}
Index: i386-common-tdep.h
===================================================================
RCS file: i386-common-tdep.h
diff -N i386-common-tdep.h
--- /dev/null	1 Jan 1970 00:00:00 -0000
+++ i386-common-tdep.h	30 Aug 2002 13:42:51 -0000
@@ -0,0 +1,32 @@
+/* Target-dependent code common for both i386 and x86-64 archs.
+
+   Copyright 2002 Free Software Foundation, Inc.
+
+   Contributed by Michal Ludvig, SuSE Labs.
+
+   This file is part of GDB.
+
+   This program is free software; you can redistribute it and/or modify
+   it under the terms of the GNU General Public License as published by
+   the Free Software Foundation; either version 2 of the License, or
+   (at your option) any later version.
+
+   This program is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+   GNU General Public License for more details.
+
+   You should have received a copy of the GNU General Public License
+   along with this program; if not, write to the Free Software
+   Foundation, Inc., 59 Temple Place - Suite 330,
+   Boston, MA 02111-1307, USA.  */
+
+#ifndef I386_COMMON_TDEP_H
+#define I386_COMMON_TDEP_H
+
+#include "gdbtypes.h"
+
+extern struct type *builtin_type_i386_eflags;
+extern struct type *builtin_type_simd_mxcsr;
+
+#endif
Index: i386-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/i386-tdep.c,v
retrieving revision 1.85
diff -u -p -r1.85 i386-tdep.c
--- i386-tdep.c	26 Aug 2002 18:35:25 -0000	1.85
+++ i386-tdep.c	30 Aug 2002 13:42:51 -0000
@@ -40,6 +40,7 @@
 
 #include "i386-tdep.h"
 #include "i387-tdep.h"
+#include "i386-common-tdep.h"
 
 /* Names of the registers.  The first 10 registers match the register
    numbering scheme used by GCC for stabs and DWARF.  */
@@ -1101,6 +1102,12 @@ 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 (regnum == MXCSR_REGNUM)
+    return builtin_type_simd_mxcsr;
 
   if (IS_FP_REGNUM (regnum))
     return builtin_type_i387_ext;
Index: valprint.c
===================================================================
RCS file: /cvs/src/src/gdb/valprint.c,v
retrieving revision 1.28
diff -u -p -r1.28 valprint.c
--- valprint.c	24 Aug 2002 00:40:59 -0000	1.28
+++ valprint.c	30 Aug 2002 13:42:51 -0000
@@ -1183,6 +1183,39 @@ val_print_string (CORE_ADDR addr, int le
 }
 \f
 
+void
+val_print_type_code_flags (char *valaddr, struct type *type, 
+		           int format, int size, 
+			   struct ui_file *stream)
+{
+  unsigned int len;
+  int i;
+  LONGEST val;
+  
+  if (format)
+    print_scalar_formatted (valaddr, type, format, 0, stream);
+  else
+  {
+    len = TYPE_NFIELDS (type);
+    val = unpack_long (type, valaddr);
+    fputs_filtered("[", stream);
+    for (i = len-1; i >= 0; i--)
+      {
+        QUIT;
+        if (TYPE_FIELD_BITPOS (type, i) != -1 && val & (1 << i))
+        if (val & (1 << i))
+        {
+      	if(TYPE_FIELD_NAME (type, i))
+            fprintf_filtered (stream, " %s", TYPE_FIELD_NAME (type, i));
+      	else
+            fprintf_filtered (stream, " #%d", i);
+      			  
+        }
+      }
+    fputs_filtered(" ]", stream);
+  }
+}
+
 /* Validate an input or output radix setting, and make sure the user
    knows what they really did here.  Radix setting is confusing, e.g.
    setting the input radix to "10" never changes it!  */
Index: valprint.h
===================================================================
RCS file: /cvs/src/src/gdb/valprint.h,v
retrieving revision 1.3
diff -u -p -r1.3 valprint.h
--- valprint.h	21 Oct 2001 19:20:30 -0000	1.3
+++ valprint.h	30 Aug 2002 13:42:51 -0000
@@ -49,6 +49,10 @@ extern void val_print_array_elements (st
 extern void val_print_type_code_int (struct type *, char *,
 				     struct ui_file *);
 
+extern void val_print_type_code_flags (char *valaddr, struct type *type, 
+				       int format, int size, 
+				       struct ui_file *stream);
+
 extern void print_binary_chars (struct ui_file *, unsigned char *,
 				unsigned int);
 
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	3 Sep 2002 08:27:59 -0000
@@ -737,7 +737,7 @@ value_concat (struct value *arg1, struct
 
 /* Perform a binary operation on two operands which have reasonable
    representations as integers or floats.  This includes booleans,
-   characters, integers, or floats.
+   characters, integers, floats, or BitFlags.
    Does not support addition and subtraction on pointers;
    use value_add or value_sub if you want to handle those possibilities.  */
 
@@ -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
Index: values.c
===================================================================
RCS file: /cvs/src/src/gdb/values.c,v
retrieving revision 1.40
diff -u -p -r1.40 values.c
--- values.c	24 Aug 2002 00:21:35 -0000	1.40
+++ values.c	30 Aug 2002 13:42:51 -0000
@@ -696,6 +696,7 @@ unpack_long (struct type *type, char *va
     case TYPE_CODE_ENUM:
     case TYPE_CODE_BOOL:
     case TYPE_CODE_INT:
+    case TYPE_CODE_FLAGS:
     case TYPE_CODE_CHAR:
     case TYPE_CODE_RANGE:
       if (nosign)
Index: x86-64-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/x86-64-tdep.c,v
retrieving revision 1.26
diff -u -p -r1.26 x86-64-tdep.c
--- x86-64-tdep.c	24 Aug 2002 00:21:35 -0000	1.26
+++ x86-64-tdep.c	30 Aug 2002 13:42:51 -0000
@@ -33,6 +33,8 @@
 #include "dwarf2cfi.h"
 #include "gdb_assert.h"
 
+#include "i386-common-tdep.h"
+
 /* Register numbers of various important registers.  */
 #define RAX_REGNUM 0
 #define RDX_REGNUM 3
@@ -68,7 +70,7 @@ static struct register_info x86_64_regis
   /* 14 */ {8, "r14", &builtin_type_int64},
   /* 15 */ {8, "r15", &builtin_type_int64},
   /* 16 */ {8, "rip", &builtin_type_void_func_ptr},
-  /* 17 */ {4, "eflags", &builtin_type_int32},
+  /* 17 */ {4, "eflags", &builtin_type_i386_eflags},
   /* 18 */ {4, "ds", &builtin_type_int32},
   /* 19 */ {4, "es", &builtin_type_int32},
   /* 20 */ {4, "fs", &builtin_type_int32},
@@ -105,7 +107,7 @@ static struct register_info x86_64_regis
   /* 51 */ {16, "xmm13", &builtin_type_v4sf},
   /* 52 */ {16, "xmm14", &builtin_type_v4sf},
   /* 53 */ {16, "xmm15", &builtin_type_v4sf},
-  /* 54 */ {4, "mxcsr", &builtin_type_int32}
+  /* 54 */ {4, "mxcsr", &builtin_type_simd_mxcsr}
 };
 
 /* This array is a mapping from Dwarf-2 register 
Index: ada-valprint.c
===================================================================
RCS file: /cvs/src/src/gdb/ada-valprint.c,v
retrieving revision 1.4
diff -u -p -r1.4 ada-valprint.c
--- ada-valprint.c	18 Aug 2002 18:07:33 -0000	1.4
+++ ada-valprint.c	30 Aug 2002 13:42:50 -0000
@@ -777,6 +777,11 @@ ada_val_print_1 (struct type *type, char
 	    fputs_filtered ("???", stream);
 	}
       break;
+
+    case TYPE_CODE_FLAGS:
+      val_print_type_code_flags (valaddr + embedded_offset, type, 
+		                 format, 0, stream);
+      break;
     }
   return 0;
 }
Index: c-valprint.c
===================================================================
RCS file: /cvs/src/src/gdb/c-valprint.c,v
retrieving revision 1.14
diff -u -p -r1.14 c-valprint.c
--- c-valprint.c	27 Aug 2002 22:37:06 -0000	1.14
+++ c-valprint.c	30 Aug 2002 13:42:50 -0000
@@ -486,6 +486,11 @@ c_val_print (struct type *type, char *va
       fprintf_filtered (stream, " * I");
       break;
 
+    case TYPE_CODE_FLAGS:
+      val_print_type_code_flags (valaddr + embedded_offset, type, 
+		                 format, 0, stream);
+      break;
+
     default:
       error ("Invalid C/C++ type code %d in symbol table.", TYPE_CODE (type));
     }
Index: f-valprint.c
===================================================================
RCS file: /cvs/src/src/gdb/f-valprint.c,v
retrieving revision 1.6
diff -u -p -r1.6 f-valprint.c
--- f-valprint.c	7 Mar 2001 02:57:08 -0000	1.6
+++ f-valprint.c	30 Aug 2002 13:42:50 -0000
@@ -544,6 +544,11 @@ f_val_print (struct type *type, char *va
       fprintf_filtered (stream, "<incomplete type>");
       break;
 
+    case TYPE_CODE_FLAGS:
+      val_print_type_code_flags (valaddr + embedded_offset, type, 
+		                 format, 0, stream);
+      break;
+
     default:
       error ("Invalid F77 type code %d in symbol table.", TYPE_CODE (type));
     }
Index: jv-valprint.c
===================================================================
RCS file: /cvs/src/src/gdb/jv-valprint.c,v
retrieving revision 1.11
diff -u -p -r1.11 jv-valprint.c
--- jv-valprint.c	27 Aug 2002 22:37:06 -0000	1.11
+++ jv-valprint.c	30 Aug 2002 13:42:51 -0000
@@ -518,6 +518,11 @@ java_val_print (struct type *type, char 
 			       recurse, pretty);
       break;
 
+    case TYPE_CODE_FLAGS:
+      val_print_type_code_flags (valaddr + embedded_offset, type, 
+		                 format, 0, stream);
+      break;
+
     default:
       return c_val_print (type, valaddr, embedded_offset, address, stream,
 			  format, deref_ref, recurse, pretty);
Index: p-valprint.c
===================================================================
RCS file: /cvs/src/src/gdb/p-valprint.c,v
retrieving revision 1.13
diff -u -p -r1.13 p-valprint.c
--- p-valprint.c	19 Aug 2002 13:12:09 -0000	1.13
+++ p-valprint.c	30 Aug 2002 13:42:51 -0000
@@ -524,6 +524,11 @@ pascal_val_print (struct type *type, cha
       fprintf_filtered (stream, "<incomplete type>");
       break;
 
+    case TYPE_CODE_FLAGS:
+      val_print_type_code_flags (valaddr + embedded_offset, type, 
+		                 format, 0, stream);
+      break;
+
     default:
       error ("Invalid pascal type code %d in symbol table.", TYPE_CODE (type));
     }
Index: config/i386/cygwin.mt
===================================================================
RCS file: /cvs/src/src/gdb/config/i386/cygwin.mt,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 cygwin.mt
--- config/i386/cygwin.mt	16 Apr 1999 01:34:17 -0000	1.1.1.1
+++ config/i386/cygwin.mt	30 Aug 2002 13:42:51 -0000
@@ -1,5 +1,5 @@
 # Target: Intel 386 run win32
-TDEPFILES= i386-tdep.o i387-tdep.o
+TDEPFILES= i386-tdep.o i386-common-tdep.o i387-tdep.o
 TM_FILE= tm-cygwin.h
 
 
Index: config/i386/embed.mt
===================================================================
RCS file: /cvs/src/src/gdb/config/i386/embed.mt,v
retrieving revision 1.3
diff -u -p -r1.3 embed.mt
--- config/i386/embed.mt	18 Nov 2001 21:28:20 -0000	1.3
+++ config/i386/embed.mt	30 Aug 2002 13:42:51 -0000
@@ -1,3 +1,3 @@
 # Target: Embedded Intel 386 
-TDEPFILES= i386-tdep.o i387-tdep.o
+TDEPFILES= i386-tdep.o i386-common-tdep.o i387-tdep.o
 TM_FILE= tm-i386.h
Index: config/i386/fbsd.mt
===================================================================
RCS file: /cvs/src/src/gdb/config/i386/fbsd.mt,v
retrieving revision 1.3
diff -u -p -r1.3 fbsd.mt
--- config/i386/fbsd.mt	13 Jul 2001 18:27:21 -0000	1.3
+++ config/i386/fbsd.mt	30 Aug 2002 13:42:51 -0000
@@ -1,3 +1,3 @@
 # Target: Intel 386 running FreeBSD
-TDEPFILES= i386-tdep.o i387-tdep.o i386bsd-tdep.o
+TDEPFILES= i386-tdep.o i386-common-tdep.o i387-tdep.o i386bsd-tdep.o
 TM_FILE= tm-fbsd.h
Index: config/i386/go32.mt
===================================================================
RCS file: /cvs/src/src/gdb/config/i386/go32.mt,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 go32.mt
--- config/i386/go32.mt	27 Apr 1999 01:26:18 -0000	1.1.1.1
+++ config/i386/go32.mt	30 Aug 2002 13:42:51 -0000
@@ -1,3 +1,3 @@
 # Target: Intel 386 running DJGPP
-TDEPFILES= i386-tdep.o i387-tdep.o
+TDEPFILES= i386-tdep.o i386-common-tdep.o i387-tdep.o
 TM_FILE= tm-go32.h
Index: config/i386/i386aix.mt
===================================================================
RCS file: /cvs/src/src/gdb/config/i386/i386aix.mt,v
retrieving revision 1.2
diff -u -p -r1.2 i386aix.mt
--- config/i386/i386aix.mt	15 Aug 2002 22:51:40 -0000	1.2
+++ config/i386/i386aix.mt	30 Aug 2002 13:42:51 -0000
@@ -3,5 +3,5 @@
 # OBSOLETE # proprietary debug info.
 # OBSOLETE #
 # OBSOLETE # Target: IBM PS/2 (i386) running AIX PS/2
-# OBSOLETE TDEPFILES= i386-tdep.o i387-tdep.o
+# OBSOLETE TDEPFILES= i386-tdep.o i386-common-tdep.o i387-tdep.o
 # OBSOLETE TM_FILE= tm-i386aix.h
Index: config/i386/i386aout.mt
===================================================================
RCS file: /cvs/src/src/gdb/config/i386/i386aout.mt,v
retrieving revision 1.2
diff -u -p -r1.2 i386aout.mt
--- config/i386/i386aout.mt	18 Aug 2002 22:14:24 -0000	1.2
+++ config/i386/i386aout.mt	30 Aug 2002 13:42:51 -0000
@@ -1,3 +1,3 @@
 # Target: Intel 386 with a.out
-TDEPFILES= i386-tdep.o i387-tdep.o
+TDEPFILES= i386-tdep.o i386-common-tdep.o i387-tdep.o
 TM_FILE= tm-i386.h
Index: config/i386/i386bsd.mt
===================================================================
RCS file: /cvs/src/src/gdb/config/i386/i386bsd.mt,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 i386bsd.mt
--- config/i386/i386bsd.mt	16 Apr 1999 01:34:18 -0000	1.1.1.1
+++ config/i386/i386bsd.mt	30 Aug 2002 13:42:51 -0000
@@ -1,3 +1,3 @@
 # Target: Intel 386 running BSD
 TM_FILE= tm-i386bsd.h
-TDEPFILES= i386-tdep.o
+TDEPFILES= i386-tdep.o i386-common-tdep.o
Index: config/i386/i386gnu.mt
===================================================================
RCS file: /cvs/src/src/gdb/config/i386/i386gnu.mt,v
retrieving revision 1.3
diff -u -p -r1.3 i386gnu.mt
--- config/i386/i386gnu.mt	15 Aug 2002 22:24:01 -0000	1.3
+++ config/i386/i386gnu.mt	30 Aug 2002 13:42:51 -0000
@@ -1,3 +1,3 @@
 # Target: Intel 386 running the GNU Hurd
-TDEPFILES= i386-tdep.o i387-tdep.o i386gnu-tdep.o
+TDEPFILES= i386-tdep.o i386-common-tdep.o i387-tdep.o i386gnu-tdep.o
 TM_FILE= tm-i386v4.h
Index: config/i386/i386lynx.mt
===================================================================
RCS file: /cvs/src/src/gdb/config/i386/i386lynx.mt,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 i386lynx.mt
--- config/i386/i386lynx.mt	16 Apr 1999 01:34:18 -0000	1.1.1.1
+++ config/i386/i386lynx.mt	30 Aug 2002 13:42:51 -0000
@@ -1,3 +1,3 @@
 # Target: Intel 386 running LynxOS
-TDEPFILES= coff-solib.o i386-tdep.o i386ly-tdep.o
+TDEPFILES= coff-solib.o i386-tdep.o i386-common-tdep.o i386ly-tdep.o
 TM_FILE= tm-i386lynx.h
Index: config/i386/i386m3.mt
===================================================================
RCS file: /cvs/src/src/gdb/config/i386/i386m3.mt,v
retrieving revision 1.2
diff -u -p -r1.2 i386m3.mt
--- config/i386/i386m3.mt	18 Aug 2002 16:32:14 -0000	1.2
+++ config/i386/i386m3.mt	30 Aug 2002 13:42:51 -0000
@@ -1,3 +1,3 @@
 # OBSOLETE # Target: Intel 386 with a.out under Mach 3
-# OBSOLETE TDEPFILES= i386-tdep.o 
+# OBSOLETE TDEPFILES= i386-tdep.o i386-common-tdep.o 
 # OBSOLETE TM_FILE= tm-i386m3.h
Index: config/i386/i386mk.mt
===================================================================
RCS file: /cvs/src/src/gdb/config/i386/i386mk.mt,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 i386mk.mt
--- config/i386/i386mk.mt	16 Apr 1999 01:34:18 -0000	1.1.1.1
+++ config/i386/i386mk.mt	30 Aug 2002 13:42:51 -0000
@@ -1,5 +1,5 @@
 # Target: Intel 386 with a.out in osf 1/mk
-TDEPFILES= i386-tdep.o 
+TDEPFILES= i386-tdep.o i386-common-tdep.o 
 TM_FILE= tm-i386osf1mk.h
 
 TM_CFLAGS= -I/usr/mach3/include
Index: config/i386/i386nw.mt
===================================================================
RCS file: /cvs/src/src/gdb/config/i386/i386nw.mt,v
retrieving revision 1.2
diff -u -p -r1.2 i386nw.mt
--- config/i386/i386nw.mt	14 Jun 2002 19:42:20 -0000	1.2
+++ config/i386/i386nw.mt	30 Aug 2002 13:42:51 -0000
@@ -1,3 +1,3 @@
 # Target: Intel 386 running NetWare
-TDEPFILES= i386-tdep.o i387-tdep.o
+TDEPFILES= i386-tdep.o i386-common-tdep.o i387-tdep.o
 TM_FILE= tm-i386.h
Index: config/i386/i386os9k.mt
===================================================================
RCS file: /cvs/src/src/gdb/config/i386/i386os9k.mt,v
retrieving revision 1.2
diff -u -p -r1.2 i386os9k.mt
--- config/i386/i386os9k.mt	16 Jul 2002 15:19:19 -0000	1.2
+++ config/i386/i386os9k.mt	30 Aug 2002 13:42:51 -0000
@@ -1,3 +1,3 @@
 # OBSOLETE # Target: Intel 386 running OS9000
-# OBSOLETE TDEPFILES= i386-tdep.o remote-os9k.o
+# OBSOLETE TDEPFILES= i386-tdep.o i386-common-tdep.o remote-os9k.o
 # OBSOLETE TM_FILE= tm-i386os9k.h
Index: config/i386/i386sco5.mt
===================================================================
RCS file: /cvs/src/src/gdb/config/i386/i386sco5.mt,v
retrieving revision 1.2
diff -u -p -r1.2 i386sco5.mt
--- config/i386/i386sco5.mt	18 Aug 2002 22:23:32 -0000	1.2
+++ config/i386/i386sco5.mt	30 Aug 2002 13:42:51 -0000
@@ -1,3 +1,3 @@
 # Target: Intel 386 running SCO Open Server 5
-TDEPFILES= i386-tdep.o i387-tdep.o
+TDEPFILES= i386-tdep.o i386-common-tdep.o i387-tdep.o
 TM_FILE= tm-i386v4.h
Index: config/i386/i386sol2.mt
===================================================================
RCS file: /cvs/src/src/gdb/config/i386/i386sol2.mt,v
retrieving revision 1.4
diff -u -p -r1.4 i386sol2.mt
--- config/i386/i386sol2.mt	14 Jun 2002 19:42:20 -0000	1.4
+++ config/i386/i386sol2.mt	30 Aug 2002 13:42:51 -0000
@@ -1,3 +1,3 @@
 # Target: Intel 386 running Solaris 2 (SVR4)
-TDEPFILES= i386-tdep.o i387-tdep.o i386-sol2-tdep.o i386bsd-tdep.o
+TDEPFILES= i386-tdep.o i386-common-tdep.o i387-tdep.o i386-sol2-tdep.o i386bsd-tdep.o
 TM_FILE= tm-i386sol2.h
Index: config/i386/i386v.mt
===================================================================
RCS file: /cvs/src/src/gdb/config/i386/i386v.mt,v
retrieving revision 1.2
diff -u -p -r1.2 i386v.mt
--- config/i386/i386v.mt	18 Aug 2002 22:14:24 -0000	1.2
+++ config/i386/i386v.mt	30 Aug 2002 13:42:51 -0000
@@ -1,3 +1,3 @@
 # Target: Intel 386 running System V
-TDEPFILES= i386-tdep.o i387-tdep.o
+TDEPFILES= i386-tdep.o i386-common-tdep.o i387-tdep.o
 TM_FILE= tm-i386.h
Index: config/i386/i386v4.mt
===================================================================
RCS file: /cvs/src/src/gdb/config/i386/i386v4.mt,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 i386v4.mt
--- config/i386/i386v4.mt	16 Apr 1999 01:34:19 -0000	1.1.1.1
+++ config/i386/i386v4.mt	30 Aug 2002 13:42:51 -0000
@@ -1,3 +1,3 @@
 # Target: Intel 386 running SVR4
-TDEPFILES= i386-tdep.o i387-tdep.o
+TDEPFILES= i386-tdep.o i386-common-tdep.o i387-tdep.o
 TM_FILE= tm-i386v4.h
Index: config/i386/i386v42mp.mt
===================================================================
RCS file: /cvs/src/src/gdb/config/i386/i386v42mp.mt,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 i386v42mp.mt
--- config/i386/i386v42mp.mt	16 Apr 1999 01:34:19 -0000	1.1.1.1
+++ config/i386/i386v42mp.mt	30 Aug 2002 13:42:51 -0000
@@ -1,3 +1,3 @@
 # Target: Intel 386 running SVR4.2MP
-TDEPFILES= i386-tdep.o i387-tdep.o
+TDEPFILES= i386-tdep.o i386-common-tdep.o i387-tdep.o
 TM_FILE= tm-i386v42mp.h
Index: config/i386/linux.mt
===================================================================
RCS file: /cvs/src/src/gdb/config/i386/linux.mt,v
retrieving revision 1.5
diff -u -p -r1.5 linux.mt
--- config/i386/linux.mt	14 Feb 2002 05:48:33 -0000	1.5
+++ config/i386/linux.mt	30 Aug 2002 13:42:51 -0000
@@ -1,5 +1,5 @@
 # Target: Intel 386 running GNU/Linux
-TDEPFILES= i386-tdep.o i386-linux-tdep.o i387-tdep.o \
+TDEPFILES= i386-tdep.o i386-common-tdep.o i386-linux-tdep.o i387-tdep.o \
 	solib.o solib-svr4.o solib-legacy.o
 TM_FILE= tm-linux.h
 
Index: config/i386/nbsdaout.mt
===================================================================
RCS file: /cvs/src/src/gdb/config/i386/nbsdaout.mt,v
retrieving revision 1.1
diff -u -p -r1.1 nbsdaout.mt
--- config/i386/nbsdaout.mt	22 May 2002 03:59:54 -0000	1.1
+++ config/i386/nbsdaout.mt	30 Aug 2002 13:42:51 -0000
@@ -1,3 +1,3 @@
 # Target: Intel 386 running NetBSD
-TDEPFILES= i386-tdep.o i387-tdep.o i386bsd-tdep.o i386nbsd-tdep.o corelow.o
+TDEPFILES= i386-tdep.o i386-common-tdep.o i387-tdep.o i386bsd-tdep.o i386nbsd-tdep.o corelow.o
 TM_FILE= tm-nbsdaout.h
Index: config/i386/nbsdelf.mt
===================================================================
RCS file: /cvs/src/src/gdb/config/i386/nbsdelf.mt,v
retrieving revision 1.9
diff -u -p -r1.9 nbsdelf.mt
--- config/i386/nbsdelf.mt	22 May 2002 03:59:54 -0000	1.9
+++ config/i386/nbsdelf.mt	30 Aug 2002 13:42:51 -0000
@@ -1,3 +1,3 @@
 # Target: Intel 386 running NetBSD
-TDEPFILES= i386-tdep.o i387-tdep.o i386bsd-tdep.o i386nbsd-tdep.o corelow.o
+TDEPFILES= i386-tdep.o i386-common-tdep.o i387-tdep.o i386bsd-tdep.o i386nbsd-tdep.o corelow.o
 TM_FILE= tm-nbsd.h
Index: config/i386/ncr3000.mt
===================================================================
RCS file: /cvs/src/src/gdb/config/i386/ncr3000.mt,v
retrieving revision 1.3
diff -u -p -r1.3 ncr3000.mt
--- config/i386/ncr3000.mt	10 Mar 2001 06:17:21 -0000	1.3
+++ config/i386/ncr3000.mt	30 Aug 2002 13:42:51 -0000
@@ -1,3 +1,3 @@
 # Target: Intel 386 running SVR4
-TDEPFILES= i386-tdep.o i387-tdep.o solib.o solib-svr4.o solib-legacy.o
+TDEPFILES= i386-tdep.o i386-common-tdep.o i387-tdep.o solib.o solib-svr4.o solib-legacy.o
 TM_FILE= tm-i386v4.h
Index: config/i386/ptx.mt
===================================================================
RCS file: /cvs/src/src/gdb/config/i386/ptx.mt,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 ptx.mt
--- config/i386/ptx.mt	16 Apr 1999 01:34:19 -0000	1.1.1.1
+++ config/i386/ptx.mt	30 Aug 2002 13:42:51 -0000
@@ -1,3 +1,3 @@
 # Target: Sequent Symmetry running ptx 2.0, with Weitek 1167 or i387.
-TDEPFILES= symm-tdep.o i387-tdep.o i386-tdep.o
+TDEPFILES= symm-tdep.o i387-tdep.o i386-tdep.o i386-common-tdep.o
 TM_FILE= tm-ptx.h
Index: config/i386/ptx4.mt
===================================================================
RCS file: /cvs/src/src/gdb/config/i386/ptx4.mt,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 ptx4.mt
--- config/i386/ptx4.mt	16 Apr 1999 01:34:19 -0000	1.1.1.1
+++ config/i386/ptx4.mt	30 Aug 2002 13:42:51 -0000
@@ -1,3 +1,3 @@
 # Target: Sequent Symmetry running ptx 4.0, with Weitek 1167 or i387.
-TDEPFILES= symm-tdep.o i387-tdep.o i386-tdep.o
+TDEPFILES= symm-tdep.o i387-tdep.o i386-tdep.o i386-common-tdep.o
 TM_FILE= tm-ptx4.h
Index: config/i386/symmetry.mt
===================================================================
RCS file: /cvs/src/src/gdb/config/i386/symmetry.mt,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 symmetry.mt
--- config/i386/symmetry.mt	16 Apr 1999 01:34:19 -0000	1.1.1.1
+++ config/i386/symmetry.mt	30 Aug 2002 13:42:51 -0000
@@ -1,3 +1,3 @@
 # Target: Sequent Symmetry running Dynix 3.0, with Weitek 1167 or i387.
-TDEPFILES= i386-tdep.o symm-tdep.o i387-tdep.o
+TDEPFILES= i386-tdep.o i386-common-tdep.o symm-tdep.o i387-tdep.o
 TM_FILE= tm-symmetry.h
Index: config/i386/vxworks.mt
===================================================================
RCS file: /cvs/src/src/gdb/config/i386/vxworks.mt,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 vxworks.mt
--- config/i386/vxworks.mt	19 Jul 1999 23:28:21 -0000	1.1.1.1
+++ config/i386/vxworks.mt	30 Aug 2002 13:42:51 -0000
@@ -1,3 +1,3 @@
 # Target: i386 running VxWorks
-TDEPFILES= i386-tdep.o i387-tdep.o 
+TDEPFILES= i386-tdep.o i386-common-tdep.o i387-tdep.o 
 TM_FILE= tm-vxworks.h
Index: config/i386/x86-64linux.mt
===================================================================
RCS file: /cvs/src/src/gdb/config/i386/x86-64linux.mt,v
retrieving revision 1.5
diff -u -p -r1.5 x86-64linux.mt
--- config/i386/x86-64linux.mt	1 Jul 2002 22:09:52 -0000	1.5
+++ config/i386/x86-64linux.mt	30 Aug 2002 13:42:51 -0000
@@ -1,6 +1,7 @@
 # Target: AMD x86-64 running GNU/Linux
 TDEPFILES= x86-64-tdep.o x86-64-linux-tdep.o dwarf2cfi.o \
-	solib.o solib-svr4.o solib-legacy.o
+	solib.o solib-svr4.o solib-legacy.o \
+	i386-common-tdep.o
 
 GDB_MULTI_ARCH=GDB_MULTI_ARCH_TM
 

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

[Pierre Muller]

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

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

[Daniel Jacobowitz]

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.

You should be able to make the parser promote an lvalue of
TYPE_CODE_FLAGS to TYPE_CODE_INT...

> >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.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

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

[Michal Ludvig]

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.

> or willsomething like
>    set $eflags = $eflags | [ZF]
> be possible ?

I don't know how to do this :-(

Michal Ludvig
-- 
* SuSE CR, s.r.o     * mludvig@suse.cz
* +420 2 9654 5373   * http://www.suse.cz

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

[Pierre Muller]

At 15:52 30/08/2002 , vous avez écrit:
>Andrew Cagney wrote:
>>Is there any immediate technical problem stopping x86-64 linking in i386-tdep.c?  (Yes scary, multi-arch).
>
>Yes, if both are linked, the gdbarch initialisation is attempted to be done twice and gdb crashes. I could add an #ifdef to optionally ignore some parts of i386-tdep, but IMHO it's better to introduce a new file as DanielJ proposed. See the patch. I've moved both new builtin types and their initialisation to i386-common-tdep.c and modified all config/i386/*.mt files to require it. This approach shouldn't harm MarkK's effort at all.
>Any objections or can I commit it?

This looks quite good in general,
but I don't have the time to test the patch myself...

I was just afraid of one thing :

   will it still be possible to do arithmetics
on those registers ?

   say that you want to clear on flag 
in the $eflags registers

before your patch you could do
  
  set $eflags &=0xfffe
if you wanted to clear the flag at position zero.
Will this still be possible without typecasting the flag register ?
or willsomething like
   set $eflags = $eflags | [ZF]
be possible ?
  




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

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

[Michal Ludvig]

Mark Kettenis wrote:
> Isn't going to happen before branching.  My problem is that I don't
> have the opportunity to test an x86-64 target.  I might have a go at
> integrating bits, but Michal will probably have to test those changes
> for me.

Sure, no problem. Just send me the patch and tell what should I test.

Michal Ludvig
-- 
* SuSE CR, s.r.o     * mludvig@suse.cz
* +420 2 9654 5373   * http://www.suse.cz

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

[Michal Ludvig]

[-- Attachment #1: Type: text/plain, Size: 711 bytes --]

Andrew Cagney wrote:
> Is there any immediate technical problem stopping x86-64 linking in 
> i386-tdep.c?  (Yes scary, multi-arch).

Yes, if both are linked, the gdbarch initialisation is attempted to be 
done twice and gdb crashes. I could add an #ifdef to optionally ignore 
some parts of i386-tdep, but IMHO it's better to introduce a new file as 
DanielJ proposed. See the patch. I've moved both new builtin types and 
their initialisation to i386-common-tdep.c and modified all 
config/i386/*.mt files to require it. This approach shouldn't harm 
MarkK's effort at all.
Any objections or can I commit it?

Michal Ludvig
-- 
* SuSE CR, s.r.o     * mludvig@suse.cz
* +420 2 9654 5373   * http://www.suse.cz

[-- Attachment #2: flags-5.diff --]
[-- Type: text/plain, Size: 34573 bytes --]

2002-08-29  Michal Ludvig  <mludvig@suse.cz>

	* gdbtypes.c 	(add_flag_ignore, add_flag_name, init_flags_type): Added.
	(is_integral_type, rank_one_type, recursive_dump_type): Added
	TYPE_CODE_FLAGS handling.
	* gdbtypes.h (type_code): Added TYPE_CODE_FLAGS.
	* valprint.c (val_print_type_code_flags): Added.
	* valprint.h (val_print_type_code_flags): Added.
	* values.c (unpack_long): Added TYPE_CODE_FLAGS handling.
	* i386-common-tdep.o: New file.
	(builtin_type_i386_eflags): Added.
	(builtin_type_simd_mxcsr): Added.
	(_initialize_i386_common_tdep): Perform builtin_type_i386_eflags 
	and builtin_type_simd_mxcsr initialization.
	* i386-common-tdep.h: New file.
	(builtin_type_i386_eflags): Added.
	(builtin_type_simd_mxcsr): Added.
	* i386-tdep.c (i386_register_virtual_type): Added eflags and 
	mxcsr registers handling.
	* x86-64-tdep.c (x86_64_register_info_table): Changed type 
	of eflags and mxcsr registers.
	* ada-valprint.c (ada_val_print_1): Added TYPE_CODE_FLAGS case.
	* c-valprint.c (c_val_print): Ditto.
	* f-valprint.c (f_val_print): Ditto.
	* jv-valprint.c (java_val_print): Ditto.
	* p-valprint.c (pascal_val_print): Ditto.
	* config/i386/x86-64linux.mt: Added i386-common-tdep.o
	* config/i386/i386aix.mt: Ditto.
	* config/i386/i386aout.mt: Ditto.
	* config/i386/i386bsd.mt: Ditto.
	* config/i386/i386gnu.mt: Ditto.
	* config/i386/i386lynx.mt: Ditto.
	* config/i386/i386m3.mt: Ditto.
	* config/i386/i386mk.mt: Ditto.
	* config/i386/i386nw.mt: Ditto.
	* config/i386/i386os9k.mt: Ditto.
	* config/i386/i386sco5.mt: Ditto.
	* config/i386/i386sol2.mt: Ditto.
	* config/i386/i386v.mt: Ditto.
	* config/i386/i386v4.mt: Ditto.
	* config/i386/i386v42mp.mt: Ditto.
	* config/i386/linux.mt: Ditto.
	* config/i386/cygwin.mt: Ditto.
	* config/i386/embed.mt: Ditto.
	* config/i386/fbsd.mt: Ditto.
	* config/i386/go32.mt: Ditto.
	* config/i386/nbsdaout.mt: Ditto.
	* config/i386/nbsdelf.mt: Ditto.
	* config/i386/ncr3000.mt: Ditto.
	* config/i386/ptx.mt: Ditto.
	* config/i386/ptx4.mt: Ditto.
	* config/i386/symmetry.mt: Ditto.
	* config/i386/vxworks.mt: Ditto.

Index: gdbtypes.c
===================================================================
RCS file: /cvs/src/src/gdb/gdbtypes.c,v
retrieving revision 1.56
diff -u -p -r1.56 gdbtypes.c
--- gdbtypes.c	20 Aug 2002 19:57:32 -0000	1.56
+++ gdbtypes.c	30 Aug 2002 13:42:50 -0000
@@ -782,6 +782,61 @@ create_set_type (struct type *result_typ
   return (result_type);
 }
 
+/*
+ * - The following three functions are intended to be used for BitFlags 
+ *   types (e.g. i386's EFLAGS register).
+ * - A BitFlags type is an integer where bits may have a symbolic name 
+ *   to be printed when the bit is set.
+ * - Printing is done in <lang>_val_print() under a TYPE_CODE_FLAGS label.
+ * - Add symbolic names for relevant bits using add_flag_name() after
+ *   initializing the BitFlags type.
+ */
+void
+add_flag_ignore (struct type *type, int bitpos)
+{
+	TYPE_FIELD_BITPOS (type, bitpos) = -1;
+}
+
+void
+add_flag_name (struct type *type, int bitpos, char *name)
+{
+	int namelen;
+	
+	gdb_assert (TYPE_CODE (type) == TYPE_CODE_FLAGS);
+	gdb_assert (bitpos < TYPE_NFIELDS (type));
+	gdb_assert (bitpos >= 0);
+	
+	namelen=strlen(name)+1;
+	TYPE_FIELD_NAME (type, bitpos) = xmalloc (namelen);
+	snprintf(TYPE_FIELD_NAME (type, bitpos), namelen, "%s", name);	
+
+	TYPE_FIELD_BITPOS (type, bitpos) = bitpos;
+}
+
+struct type *
+init_flags_type (int bitlength, char *name, struct objfile *objfile)
+{
+  register struct type *type;
+  
+  type = alloc_type (objfile);
+  
+  TYPE_CODE (type) = TYPE_CODE_FLAGS;
+  TYPE_LENGTH (type) = (bitlength + TARGET_CHAR_BIT - 1) / TARGET_CHAR_BIT;
+  TYPE_FLAGS (type) = TYPE_FLAG_UNSIGNED;
+  TYPE_NFIELDS (type) = bitlength;
+  TYPE_FIELDS (type) = (struct field *)
+    TYPE_ALLOC (type, bitlength * sizeof (struct field));
+  memset (TYPE_FIELDS (type), 0, sizeof (struct field));
+
+  if ((name != NULL) && (objfile != NULL))
+      TYPE_NAME (type) =
+	obsavestring (name, strlen (name), &objfile->type_obstack);
+  else
+      TYPE_NAME (type) = name;
+  
+  return (type);
+}
+
 /* Construct and return a type of the form:
 	struct NAME { ELT_TYPE ELT_NAME[N]; }
    We use these types for SIMD registers.  For example, the type of
@@ -1946,6 +2001,7 @@ is_integral_type (struct type *t)
   return
     ((t != NULL)
      && ((TYPE_CODE (t) == TYPE_CODE_INT)
+	 || (TYPE_CODE (t) == TYPE_CODE_FLAGS)
 	 || (TYPE_CODE (t) == TYPE_CODE_ENUM)
 	 || (TYPE_CODE (t) == TYPE_CODE_CHAR)
 	 || (TYPE_CODE (t) == TYPE_CODE_RANGE)
@@ -2479,6 +2535,7 @@ rank_one_type (struct type *parm, struct
 	case TYPE_CODE_FUNC:
 	  return rank_one_type (TYPE_TARGET_TYPE (parm), arg);
 	case TYPE_CODE_INT:
+	case TYPE_CODE_FLAGS:
 	case TYPE_CODE_ENUM:
 	case TYPE_CODE_CHAR:
 	case TYPE_CODE_RANGE:
@@ -2555,6 +2612,7 @@ rank_one_type (struct type *parm, struct
 	    return INTEGER_PROMOTION_BADNESS;
 	  else
 	    return INTEGER_COERCION_BADNESS;
+        case TYPE_CODE_FLAGS:
 	case TYPE_CODE_ENUM:
 	case TYPE_CODE_CHAR:
 	case TYPE_CODE_RANGE:
@@ -2999,6 +3057,9 @@ recursive_dump_type (struct type *type, 
       break;
     case TYPE_CODE_INT:
       printf_filtered ("(TYPE_CODE_INT)");
+      break;
+    case TYPE_CODE_FLAGS:
+      printf_filtered ("(TYPE_CODE_FLAGS)");
       break;
     case TYPE_CODE_FLT:
       printf_filtered ("(TYPE_CODE_FLT)");
Index: gdbtypes.h
===================================================================
RCS file: /cvs/src/src/gdb/gdbtypes.h,v
retrieving revision 1.35
diff -u -p -r1.35 gdbtypes.h
--- gdbtypes.h	10 Aug 2002 05:12:40 -0000	1.35
+++ gdbtypes.h	30 Aug 2002 13:42:51 -0000
@@ -85,6 +85,7 @@ enum type_code
     TYPE_CODE_ENUM,		/* Enumeration type */
     TYPE_CODE_FUNC,		/* Function type */
     TYPE_CODE_INT,		/* Integer type */
+    TYPE_CODE_FLAGS,		/* BitFlags type */
 
     /* Floating type.  This is *NOT* a complex type.  Beware, there are parts
        of GDB which bogusly assume that TYPE_CODE_FLT can mean complex.  */
@@ -926,6 +927,7 @@ extern struct type *builtin_type_void_fu
 
 /* The target CPU's address type.  This is the ISA address size. */
 extern struct type *builtin_type_CORE_ADDR;
+
 /* The symbol table address type.  Some object file formats have a 32
    bit address type even though the TARGET has a 64 bit pointer type
    (cf MIPS). */
@@ -1054,6 +1056,14 @@ extern struct type *alloc_type (struct o
 
 extern struct type *init_type (enum type_code, int, int, char *,
 			       struct objfile *);
+
+/* Helper functions to construct BitField type.  
+   See description in gdbarch.c for details.  */
+
+struct type *init_flags_type (int bitlength, char *name, 
+		              struct objfile *objfile);
+void add_flag_ignore (struct type *type, int bitpos);
+void add_flag_name (struct type *type, int bitpos, char *name);
 
 /* Helper functions to construct a struct or record type.  An
    initially empty type is created using init_composite_type().
Index: i386-common-tdep.c
===================================================================
RCS file: i386-common-tdep.c
diff -N i386-common-tdep.c
--- /dev/null	1 Jan 1970 00:00:00 -0000
+++ i386-common-tdep.c	30 Aug 2002 13:42:51 -0000
@@ -0,0 +1,75 @@
+/* Target-dependent code common for both i386 and x86-64 archs.
+
+   Copyright 2002 Free Software Foundation, Inc.
+
+   Contributed by Michal Ludvig, SuSE Labs.
+
+   This file is part of GDB.
+
+   This program is free software; you can redistribute it and/or modify
+   it under the terms of the GNU General Public License as published by
+   the Free Software Foundation; either version 2 of the License, or
+   (at your option) any later version.
+
+   This program is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+   GNU General Public License for more details.
+
+   You should have received a copy of the GNU General Public License
+   along with this program; if not, write to the Free Software
+   Foundation, Inc., 59 Temple Place - Suite 330,
+   Boston, MA 02111-1307, USA.  */
+
+#include "defs.h"
+#include "gdbtypes.h"
+
+struct type *builtin_type_i386_eflags;
+struct type *builtin_type_simd_mxcsr;
+
+void
+_initialize_i386_common_tdep (void)
+{
+  builtin_type_i386_eflags = 
+    init_flags_type (32 /* EFLAGS_LENGTH */, 
+    	       "__i386_eflags", (struct objfile *) NULL);
+  add_flag_name (builtin_type_i386_eflags, 0, "CF");
+  add_flag_ignore (builtin_type_i386_eflags, 1);
+  add_flag_name (builtin_type_i386_eflags, 2, "PF");
+  add_flag_name (builtin_type_i386_eflags, 4, "AF");
+  add_flag_name (builtin_type_i386_eflags, 6, "ZF");
+  add_flag_name (builtin_type_i386_eflags, 7, "SF");
+  add_flag_name (builtin_type_i386_eflags, 8, "TF");
+  add_flag_name (builtin_type_i386_eflags, 9, "IF");
+  add_flag_name (builtin_type_i386_eflags, 10, "DF");
+  add_flag_name (builtin_type_i386_eflags, 11, "OF");
+  add_flag_ignore (builtin_type_i386_eflags, 12);
+  add_flag_ignore (builtin_type_i386_eflags, 13);
+  add_flag_name (builtin_type_i386_eflags, 14, "NT");
+  add_flag_name (builtin_type_i386_eflags, 16, "RF");
+  add_flag_name (builtin_type_i386_eflags, 17, "VM");
+  add_flag_name (builtin_type_i386_eflags, 18, "AC");
+  add_flag_name (builtin_type_i386_eflags, 19, "VIF");
+  add_flag_name (builtin_type_i386_eflags, 20, "VIP");
+  add_flag_name (builtin_type_i386_eflags, 21, "ID");
+  
+  builtin_type_simd_mxcsr = 
+    init_flags_type (32 /* MXCSR_LENGTH */, 
+    	       "__simd_mxcsr", (struct objfile *) NULL);
+  add_flag_name (builtin_type_simd_mxcsr, 0, "IE");
+  add_flag_name (builtin_type_simd_mxcsr, 1, "DE");
+  add_flag_name (builtin_type_simd_mxcsr, 2, "ZE");
+  add_flag_name (builtin_type_simd_mxcsr, 3, "OE");
+  add_flag_name (builtin_type_simd_mxcsr, 4, "UE");
+  add_flag_name (builtin_type_simd_mxcsr, 5, "PE");
+  add_flag_name (builtin_type_simd_mxcsr, 6, "DAZ");
+  add_flag_name (builtin_type_simd_mxcsr, 7, "IM");
+  add_flag_name (builtin_type_simd_mxcsr, 8, "DM");
+  add_flag_name (builtin_type_simd_mxcsr, 9, "ZM");
+  add_flag_name (builtin_type_simd_mxcsr, 10, "OM");
+  add_flag_name (builtin_type_simd_mxcsr, 11, "UM");
+  add_flag_name (builtin_type_simd_mxcsr, 12, "PM");
+  add_flag_name (builtin_type_simd_mxcsr, 13, "RC1");
+  add_flag_name (builtin_type_simd_mxcsr, 14, "RC2");
+  add_flag_name (builtin_type_simd_mxcsr, 15, "FZ");
+}
Index: i386-common-tdep.h
===================================================================
RCS file: i386-common-tdep.h
diff -N i386-common-tdep.h
--- /dev/null	1 Jan 1970 00:00:00 -0000
+++ i386-common-tdep.h	30 Aug 2002 13:42:51 -0000
@@ -0,0 +1,32 @@
+/* Target-dependent code common for both i386 and x86-64 archs.
+
+   Copyright 2002 Free Software Foundation, Inc.
+
+   Contributed by Michal Ludvig, SuSE Labs.
+
+   This file is part of GDB.
+
+   This program is free software; you can redistribute it and/or modify
+   it under the terms of the GNU General Public License as published by
+   the Free Software Foundation; either version 2 of the License, or
+   (at your option) any later version.
+
+   This program is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+   GNU General Public License for more details.
+
+   You should have received a copy of the GNU General Public License
+   along with this program; if not, write to the Free Software
+   Foundation, Inc., 59 Temple Place - Suite 330,
+   Boston, MA 02111-1307, USA.  */
+
+#ifndef I386_COMMON_TDEP_H
+#define I386_COMMON_TDEP_H
+
+#include "gdbtypes.h"
+
+extern struct type *builtin_type_i386_eflags;
+extern struct type *builtin_type_simd_mxcsr;
+
+#endif
Index: i386-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/i386-tdep.c,v
retrieving revision 1.85
diff -u -p -r1.85 i386-tdep.c
--- i386-tdep.c	26 Aug 2002 18:35:25 -0000	1.85
+++ i386-tdep.c	30 Aug 2002 13:42:51 -0000
@@ -40,6 +40,7 @@
 
 #include "i386-tdep.h"
 #include "i387-tdep.h"
+#include "i386-common-tdep.h"
 
 /* Names of the registers.  The first 10 registers match the register
    numbering scheme used by GCC for stabs and DWARF.  */
@@ -1101,6 +1102,12 @@ 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 (regnum == MXCSR_REGNUM)
+    return builtin_type_simd_mxcsr;
 
   if (IS_FP_REGNUM (regnum))
     return builtin_type_i387_ext;
Index: valprint.c
===================================================================
RCS file: /cvs/src/src/gdb/valprint.c,v
retrieving revision 1.28
diff -u -p -r1.28 valprint.c
--- valprint.c	24 Aug 2002 00:40:59 -0000	1.28
+++ valprint.c	30 Aug 2002 13:42:51 -0000
@@ -1183,6 +1183,39 @@ val_print_string (CORE_ADDR addr, int le
 }
 \f
 
+void
+val_print_type_code_flags (char *valaddr, struct type *type, 
+		           int format, int size, 
+			   struct ui_file *stream)
+{
+  unsigned int len;
+  int i;
+  LONGEST val;
+  
+  if (format)
+    print_scalar_formatted (valaddr, type, format, 0, stream);
+  else
+  {
+    len = TYPE_NFIELDS (type);
+    val = unpack_long (type, valaddr);
+    fputs_filtered("[", stream);
+    for (i = len-1; i >= 0; i--)
+      {
+        QUIT;
+        if (TYPE_FIELD_BITPOS (type, i) != -1 && val & (1 << i))
+        if (val & (1 << i))
+        {
+      	if(TYPE_FIELD_NAME (type, i))
+            fprintf_filtered (stream, " %s", TYPE_FIELD_NAME (type, i));
+      	else
+            fprintf_filtered (stream, " #%d", i);
+      			  
+        }
+      }
+    fputs_filtered(" ]", stream);
+  }
+}
+
 /* Validate an input or output radix setting, and make sure the user
    knows what they really did here.  Radix setting is confusing, e.g.
    setting the input radix to "10" never changes it!  */
Index: valprint.h
===================================================================
RCS file: /cvs/src/src/gdb/valprint.h,v
retrieving revision 1.3
diff -u -p -r1.3 valprint.h
--- valprint.h	21 Oct 2001 19:20:30 -0000	1.3
+++ valprint.h	30 Aug 2002 13:42:51 -0000
@@ -49,6 +49,10 @@ extern void val_print_array_elements (st
 extern void val_print_type_code_int (struct type *, char *,
 				     struct ui_file *);
 
+extern void val_print_type_code_flags (char *valaddr, struct type *type, 
+				       int format, int size, 
+				       struct ui_file *stream);
+
 extern void print_binary_chars (struct ui_file *, unsigned char *,
 				unsigned int);
 
Index: values.c
===================================================================
RCS file: /cvs/src/src/gdb/values.c,v
retrieving revision 1.40
diff -u -p -r1.40 values.c
--- values.c	24 Aug 2002 00:21:35 -0000	1.40
+++ values.c	30 Aug 2002 13:42:51 -0000
@@ -696,6 +696,7 @@ unpack_long (struct type *type, char *va
     case TYPE_CODE_ENUM:
     case TYPE_CODE_BOOL:
     case TYPE_CODE_INT:
+    case TYPE_CODE_FLAGS:
     case TYPE_CODE_CHAR:
     case TYPE_CODE_RANGE:
       if (nosign)
Index: x86-64-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/x86-64-tdep.c,v
retrieving revision 1.26
diff -u -p -r1.26 x86-64-tdep.c
--- x86-64-tdep.c	24 Aug 2002 00:21:35 -0000	1.26
+++ x86-64-tdep.c	30 Aug 2002 13:42:51 -0000
@@ -33,6 +33,8 @@
 #include "dwarf2cfi.h"
 #include "gdb_assert.h"
 
+#include "i386-common-tdep.h"
+
 /* Register numbers of various important registers.  */
 #define RAX_REGNUM 0
 #define RDX_REGNUM 3
@@ -68,7 +70,7 @@ static struct register_info x86_64_regis
   /* 14 */ {8, "r14", &builtin_type_int64},
   /* 15 */ {8, "r15", &builtin_type_int64},
   /* 16 */ {8, "rip", &builtin_type_void_func_ptr},
-  /* 17 */ {4, "eflags", &builtin_type_int32},
+  /* 17 */ {4, "eflags", &builtin_type_i386_eflags},
   /* 18 */ {4, "ds", &builtin_type_int32},
   /* 19 */ {4, "es", &builtin_type_int32},
   /* 20 */ {4, "fs", &builtin_type_int32},
@@ -105,7 +107,7 @@ static struct register_info x86_64_regis
   /* 51 */ {16, "xmm13", &builtin_type_v4sf},
   /* 52 */ {16, "xmm14", &builtin_type_v4sf},
   /* 53 */ {16, "xmm15", &builtin_type_v4sf},
-  /* 54 */ {4, "mxcsr", &builtin_type_int32}
+  /* 54 */ {4, "mxcsr", &builtin_type_simd_mxcsr}
 };
 
 /* This array is a mapping from Dwarf-2 register 
Index: ada-valprint.c
===================================================================
RCS file: /cvs/src/src/gdb/ada-valprint.c,v
retrieving revision 1.4
diff -u -p -r1.4 ada-valprint.c
--- ada-valprint.c	18 Aug 2002 18:07:33 -0000	1.4
+++ ada-valprint.c	30 Aug 2002 13:42:50 -0000
@@ -777,6 +777,11 @@ ada_val_print_1 (struct type *type, char
 	    fputs_filtered ("???", stream);
 	}
       break;
+
+    case TYPE_CODE_FLAGS:
+      val_print_type_code_flags (valaddr + embedded_offset, type, 
+		                 format, 0, stream);
+      break;
     }
   return 0;
 }
Index: c-valprint.c
===================================================================
RCS file: /cvs/src/src/gdb/c-valprint.c,v
retrieving revision 1.14
diff -u -p -r1.14 c-valprint.c
--- c-valprint.c	27 Aug 2002 22:37:06 -0000	1.14
+++ c-valprint.c	30 Aug 2002 13:42:50 -0000
@@ -486,6 +486,11 @@ c_val_print (struct type *type, char *va
       fprintf_filtered (stream, " * I");
       break;
 
+    case TYPE_CODE_FLAGS:
+      val_print_type_code_flags (valaddr + embedded_offset, type, 
+		                 format, 0, stream);
+      break;
+
     default:
       error ("Invalid C/C++ type code %d in symbol table.", TYPE_CODE (type));
     }
Index: f-valprint.c
===================================================================
RCS file: /cvs/src/src/gdb/f-valprint.c,v
retrieving revision 1.6
diff -u -p -r1.6 f-valprint.c
--- f-valprint.c	7 Mar 2001 02:57:08 -0000	1.6
+++ f-valprint.c	30 Aug 2002 13:42:50 -0000
@@ -544,6 +544,11 @@ f_val_print (struct type *type, char *va
       fprintf_filtered (stream, "<incomplete type>");
       break;
 
+    case TYPE_CODE_FLAGS:
+      val_print_type_code_flags (valaddr + embedded_offset, type, 
+		                 format, 0, stream);
+      break;
+
     default:
       error ("Invalid F77 type code %d in symbol table.", TYPE_CODE (type));
     }
Index: jv-valprint.c
===================================================================
RCS file: /cvs/src/src/gdb/jv-valprint.c,v
retrieving revision 1.11
diff -u -p -r1.11 jv-valprint.c
--- jv-valprint.c	27 Aug 2002 22:37:06 -0000	1.11
+++ jv-valprint.c	30 Aug 2002 13:42:51 -0000
@@ -518,6 +518,11 @@ java_val_print (struct type *type, char 
 			       recurse, pretty);
       break;
 
+    case TYPE_CODE_FLAGS:
+      val_print_type_code_flags (valaddr + embedded_offset, type, 
+		                 format, 0, stream);
+      break;
+
     default:
       return c_val_print (type, valaddr, embedded_offset, address, stream,
 			  format, deref_ref, recurse, pretty);
Index: p-valprint.c
===================================================================
RCS file: /cvs/src/src/gdb/p-valprint.c,v
retrieving revision 1.13
diff -u -p -r1.13 p-valprint.c
--- p-valprint.c	19 Aug 2002 13:12:09 -0000	1.13
+++ p-valprint.c	30 Aug 2002 13:42:51 -0000
@@ -524,6 +524,11 @@ pascal_val_print (struct type *type, cha
       fprintf_filtered (stream, "<incomplete type>");
       break;
 
+    case TYPE_CODE_FLAGS:
+      val_print_type_code_flags (valaddr + embedded_offset, type, 
+		                 format, 0, stream);
+      break;
+
     default:
       error ("Invalid pascal type code %d in symbol table.", TYPE_CODE (type));
     }
Index: config/i386/cygwin.mt
===================================================================
RCS file: /cvs/src/src/gdb/config/i386/cygwin.mt,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 cygwin.mt
--- config/i386/cygwin.mt	16 Apr 1999 01:34:17 -0000	1.1.1.1
+++ config/i386/cygwin.mt	30 Aug 2002 13:42:51 -0000
@@ -1,5 +1,5 @@
 # Target: Intel 386 run win32
-TDEPFILES= i386-tdep.o i387-tdep.o
+TDEPFILES= i386-tdep.o i386-common-tdep.o i387-tdep.o
 TM_FILE= tm-cygwin.h
 
 
Index: config/i386/embed.mt
===================================================================
RCS file: /cvs/src/src/gdb/config/i386/embed.mt,v
retrieving revision 1.3
diff -u -p -r1.3 embed.mt
--- config/i386/embed.mt	18 Nov 2001 21:28:20 -0000	1.3
+++ config/i386/embed.mt	30 Aug 2002 13:42:51 -0000
@@ -1,3 +1,3 @@
 # Target: Embedded Intel 386 
-TDEPFILES= i386-tdep.o i387-tdep.o
+TDEPFILES= i386-tdep.o i386-common-tdep.o i387-tdep.o
 TM_FILE= tm-i386.h
Index: config/i386/fbsd.mt
===================================================================
RCS file: /cvs/src/src/gdb/config/i386/fbsd.mt,v
retrieving revision 1.3
diff -u -p -r1.3 fbsd.mt
--- config/i386/fbsd.mt	13 Jul 2001 18:27:21 -0000	1.3
+++ config/i386/fbsd.mt	30 Aug 2002 13:42:51 -0000
@@ -1,3 +1,3 @@
 # Target: Intel 386 running FreeBSD
-TDEPFILES= i386-tdep.o i387-tdep.o i386bsd-tdep.o
+TDEPFILES= i386-tdep.o i386-common-tdep.o i387-tdep.o i386bsd-tdep.o
 TM_FILE= tm-fbsd.h
Index: config/i386/go32.mt
===================================================================
RCS file: /cvs/src/src/gdb/config/i386/go32.mt,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 go32.mt
--- config/i386/go32.mt	27 Apr 1999 01:26:18 -0000	1.1.1.1
+++ config/i386/go32.mt	30 Aug 2002 13:42:51 -0000
@@ -1,3 +1,3 @@
 # Target: Intel 386 running DJGPP
-TDEPFILES= i386-tdep.o i387-tdep.o
+TDEPFILES= i386-tdep.o i386-common-tdep.o i387-tdep.o
 TM_FILE= tm-go32.h
Index: config/i386/i386aix.mt
===================================================================
RCS file: /cvs/src/src/gdb/config/i386/i386aix.mt,v
retrieving revision 1.2
diff -u -p -r1.2 i386aix.mt
--- config/i386/i386aix.mt	15 Aug 2002 22:51:40 -0000	1.2
+++ config/i386/i386aix.mt	30 Aug 2002 13:42:51 -0000
@@ -3,5 +3,5 @@
 # OBSOLETE # proprietary debug info.
 # OBSOLETE #
 # OBSOLETE # Target: IBM PS/2 (i386) running AIX PS/2
-# OBSOLETE TDEPFILES= i386-tdep.o i387-tdep.o
+# OBSOLETE TDEPFILES= i386-tdep.o i386-common-tdep.o i387-tdep.o
 # OBSOLETE TM_FILE= tm-i386aix.h
Index: config/i386/i386aout.mt
===================================================================
RCS file: /cvs/src/src/gdb/config/i386/i386aout.mt,v
retrieving revision 1.2
diff -u -p -r1.2 i386aout.mt
--- config/i386/i386aout.mt	18 Aug 2002 22:14:24 -0000	1.2
+++ config/i386/i386aout.mt	30 Aug 2002 13:42:51 -0000
@@ -1,3 +1,3 @@
 # Target: Intel 386 with a.out
-TDEPFILES= i386-tdep.o i387-tdep.o
+TDEPFILES= i386-tdep.o i386-common-tdep.o i387-tdep.o
 TM_FILE= tm-i386.h
Index: config/i386/i386bsd.mt
===================================================================
RCS file: /cvs/src/src/gdb/config/i386/i386bsd.mt,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 i386bsd.mt
--- config/i386/i386bsd.mt	16 Apr 1999 01:34:18 -0000	1.1.1.1
+++ config/i386/i386bsd.mt	30 Aug 2002 13:42:51 -0000
@@ -1,3 +1,3 @@
 # Target: Intel 386 running BSD
 TM_FILE= tm-i386bsd.h
-TDEPFILES= i386-tdep.o
+TDEPFILES= i386-tdep.o i386-common-tdep.o
Index: config/i386/i386gnu.mt
===================================================================
RCS file: /cvs/src/src/gdb/config/i386/i386gnu.mt,v
retrieving revision 1.3
diff -u -p -r1.3 i386gnu.mt
--- config/i386/i386gnu.mt	15 Aug 2002 22:24:01 -0000	1.3
+++ config/i386/i386gnu.mt	30 Aug 2002 13:42:51 -0000
@@ -1,3 +1,3 @@
 # Target: Intel 386 running the GNU Hurd
-TDEPFILES= i386-tdep.o i387-tdep.o i386gnu-tdep.o
+TDEPFILES= i386-tdep.o i386-common-tdep.o i387-tdep.o i386gnu-tdep.o
 TM_FILE= tm-i386v4.h
Index: config/i386/i386lynx.mt
===================================================================
RCS file: /cvs/src/src/gdb/config/i386/i386lynx.mt,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 i386lynx.mt
--- config/i386/i386lynx.mt	16 Apr 1999 01:34:18 -0000	1.1.1.1
+++ config/i386/i386lynx.mt	30 Aug 2002 13:42:51 -0000
@@ -1,3 +1,3 @@
 # Target: Intel 386 running LynxOS
-TDEPFILES= coff-solib.o i386-tdep.o i386ly-tdep.o
+TDEPFILES= coff-solib.o i386-tdep.o i386-common-tdep.o i386ly-tdep.o
 TM_FILE= tm-i386lynx.h
Index: config/i386/i386m3.mt
===================================================================
RCS file: /cvs/src/src/gdb/config/i386/i386m3.mt,v
retrieving revision 1.2
diff -u -p -r1.2 i386m3.mt
--- config/i386/i386m3.mt	18 Aug 2002 16:32:14 -0000	1.2
+++ config/i386/i386m3.mt	30 Aug 2002 13:42:51 -0000
@@ -1,3 +1,3 @@
 # OBSOLETE # Target: Intel 386 with a.out under Mach 3
-# OBSOLETE TDEPFILES= i386-tdep.o 
+# OBSOLETE TDEPFILES= i386-tdep.o i386-common-tdep.o 
 # OBSOLETE TM_FILE= tm-i386m3.h
Index: config/i386/i386mk.mt
===================================================================
RCS file: /cvs/src/src/gdb/config/i386/i386mk.mt,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 i386mk.mt
--- config/i386/i386mk.mt	16 Apr 1999 01:34:18 -0000	1.1.1.1
+++ config/i386/i386mk.mt	30 Aug 2002 13:42:51 -0000
@@ -1,5 +1,5 @@
 # Target: Intel 386 with a.out in osf 1/mk
-TDEPFILES= i386-tdep.o 
+TDEPFILES= i386-tdep.o i386-common-tdep.o 
 TM_FILE= tm-i386osf1mk.h
 
 TM_CFLAGS= -I/usr/mach3/include
Index: config/i386/i386nw.mt
===================================================================
RCS file: /cvs/src/src/gdb/config/i386/i386nw.mt,v
retrieving revision 1.2
diff -u -p -r1.2 i386nw.mt
--- config/i386/i386nw.mt	14 Jun 2002 19:42:20 -0000	1.2
+++ config/i386/i386nw.mt	30 Aug 2002 13:42:51 -0000
@@ -1,3 +1,3 @@
 # Target: Intel 386 running NetWare
-TDEPFILES= i386-tdep.o i387-tdep.o
+TDEPFILES= i386-tdep.o i386-common-tdep.o i387-tdep.o
 TM_FILE= tm-i386.h
Index: config/i386/i386os9k.mt
===================================================================
RCS file: /cvs/src/src/gdb/config/i386/i386os9k.mt,v
retrieving revision 1.2
diff -u -p -r1.2 i386os9k.mt
--- config/i386/i386os9k.mt	16 Jul 2002 15:19:19 -0000	1.2
+++ config/i386/i386os9k.mt	30 Aug 2002 13:42:51 -0000
@@ -1,3 +1,3 @@
 # OBSOLETE # Target: Intel 386 running OS9000
-# OBSOLETE TDEPFILES= i386-tdep.o remote-os9k.o
+# OBSOLETE TDEPFILES= i386-tdep.o i386-common-tdep.o remote-os9k.o
 # OBSOLETE TM_FILE= tm-i386os9k.h
Index: config/i386/i386sco5.mt
===================================================================
RCS file: /cvs/src/src/gdb/config/i386/i386sco5.mt,v
retrieving revision 1.2
diff -u -p -r1.2 i386sco5.mt
--- config/i386/i386sco5.mt	18 Aug 2002 22:23:32 -0000	1.2
+++ config/i386/i386sco5.mt	30 Aug 2002 13:42:51 -0000
@@ -1,3 +1,3 @@
 # Target: Intel 386 running SCO Open Server 5
-TDEPFILES= i386-tdep.o i387-tdep.o
+TDEPFILES= i386-tdep.o i386-common-tdep.o i387-tdep.o
 TM_FILE= tm-i386v4.h
Index: config/i386/i386sol2.mt
===================================================================
RCS file: /cvs/src/src/gdb/config/i386/i386sol2.mt,v
retrieving revision 1.4
diff -u -p -r1.4 i386sol2.mt
--- config/i386/i386sol2.mt	14 Jun 2002 19:42:20 -0000	1.4
+++ config/i386/i386sol2.mt	30 Aug 2002 13:42:51 -0000
@@ -1,3 +1,3 @@
 # Target: Intel 386 running Solaris 2 (SVR4)
-TDEPFILES= i386-tdep.o i387-tdep.o i386-sol2-tdep.o i386bsd-tdep.o
+TDEPFILES= i386-tdep.o i386-common-tdep.o i387-tdep.o i386-sol2-tdep.o i386bsd-tdep.o
 TM_FILE= tm-i386sol2.h
Index: config/i386/i386v.mt
===================================================================
RCS file: /cvs/src/src/gdb/config/i386/i386v.mt,v
retrieving revision 1.2
diff -u -p -r1.2 i386v.mt
--- config/i386/i386v.mt	18 Aug 2002 22:14:24 -0000	1.2
+++ config/i386/i386v.mt	30 Aug 2002 13:42:51 -0000
@@ -1,3 +1,3 @@
 # Target: Intel 386 running System V
-TDEPFILES= i386-tdep.o i387-tdep.o
+TDEPFILES= i386-tdep.o i386-common-tdep.o i387-tdep.o
 TM_FILE= tm-i386.h
Index: config/i386/i386v4.mt
===================================================================
RCS file: /cvs/src/src/gdb/config/i386/i386v4.mt,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 i386v4.mt
--- config/i386/i386v4.mt	16 Apr 1999 01:34:19 -0000	1.1.1.1
+++ config/i386/i386v4.mt	30 Aug 2002 13:42:51 -0000
@@ -1,3 +1,3 @@
 # Target: Intel 386 running SVR4
-TDEPFILES= i386-tdep.o i387-tdep.o
+TDEPFILES= i386-tdep.o i386-common-tdep.o i387-tdep.o
 TM_FILE= tm-i386v4.h
Index: config/i386/i386v42mp.mt
===================================================================
RCS file: /cvs/src/src/gdb/config/i386/i386v42mp.mt,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 i386v42mp.mt
--- config/i386/i386v42mp.mt	16 Apr 1999 01:34:19 -0000	1.1.1.1
+++ config/i386/i386v42mp.mt	30 Aug 2002 13:42:51 -0000
@@ -1,3 +1,3 @@
 # Target: Intel 386 running SVR4.2MP
-TDEPFILES= i386-tdep.o i387-tdep.o
+TDEPFILES= i386-tdep.o i386-common-tdep.o i387-tdep.o
 TM_FILE= tm-i386v42mp.h
Index: config/i386/linux.mt
===================================================================
RCS file: /cvs/src/src/gdb/config/i386/linux.mt,v
retrieving revision 1.5
diff -u -p -r1.5 linux.mt
--- config/i386/linux.mt	14 Feb 2002 05:48:33 -0000	1.5
+++ config/i386/linux.mt	30 Aug 2002 13:42:51 -0000
@@ -1,5 +1,5 @@
 # Target: Intel 386 running GNU/Linux
-TDEPFILES= i386-tdep.o i386-linux-tdep.o i387-tdep.o \
+TDEPFILES= i386-tdep.o i386-common-tdep.o i386-linux-tdep.o i387-tdep.o \
 	solib.o solib-svr4.o solib-legacy.o
 TM_FILE= tm-linux.h
 
Index: config/i386/nbsdaout.mt
===================================================================
RCS file: /cvs/src/src/gdb/config/i386/nbsdaout.mt,v
retrieving revision 1.1
diff -u -p -r1.1 nbsdaout.mt
--- config/i386/nbsdaout.mt	22 May 2002 03:59:54 -0000	1.1
+++ config/i386/nbsdaout.mt	30 Aug 2002 13:42:51 -0000
@@ -1,3 +1,3 @@
 # Target: Intel 386 running NetBSD
-TDEPFILES= i386-tdep.o i387-tdep.o i386bsd-tdep.o i386nbsd-tdep.o corelow.o
+TDEPFILES= i386-tdep.o i386-common-tdep.o i387-tdep.o i386bsd-tdep.o i386nbsd-tdep.o corelow.o
 TM_FILE= tm-nbsdaout.h
Index: config/i386/nbsdelf.mt
===================================================================
RCS file: /cvs/src/src/gdb/config/i386/nbsdelf.mt,v
retrieving revision 1.9
diff -u -p -r1.9 nbsdelf.mt
--- config/i386/nbsdelf.mt	22 May 2002 03:59:54 -0000	1.9
+++ config/i386/nbsdelf.mt	30 Aug 2002 13:42:51 -0000
@@ -1,3 +1,3 @@
 # Target: Intel 386 running NetBSD
-TDEPFILES= i386-tdep.o i387-tdep.o i386bsd-tdep.o i386nbsd-tdep.o corelow.o
+TDEPFILES= i386-tdep.o i386-common-tdep.o i387-tdep.o i386bsd-tdep.o i386nbsd-tdep.o corelow.o
 TM_FILE= tm-nbsd.h
Index: config/i386/ncr3000.mt
===================================================================
RCS file: /cvs/src/src/gdb/config/i386/ncr3000.mt,v
retrieving revision 1.3
diff -u -p -r1.3 ncr3000.mt
--- config/i386/ncr3000.mt	10 Mar 2001 06:17:21 -0000	1.3
+++ config/i386/ncr3000.mt	30 Aug 2002 13:42:51 -0000
@@ -1,3 +1,3 @@
 # Target: Intel 386 running SVR4
-TDEPFILES= i386-tdep.o i387-tdep.o solib.o solib-svr4.o solib-legacy.o
+TDEPFILES= i386-tdep.o i386-common-tdep.o i387-tdep.o solib.o solib-svr4.o solib-legacy.o
 TM_FILE= tm-i386v4.h
Index: config/i386/ptx.mt
===================================================================
RCS file: /cvs/src/src/gdb/config/i386/ptx.mt,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 ptx.mt
--- config/i386/ptx.mt	16 Apr 1999 01:34:19 -0000	1.1.1.1
+++ config/i386/ptx.mt	30 Aug 2002 13:42:51 -0000
@@ -1,3 +1,3 @@
 # Target: Sequent Symmetry running ptx 2.0, with Weitek 1167 or i387.
-TDEPFILES= symm-tdep.o i387-tdep.o i386-tdep.o
+TDEPFILES= symm-tdep.o i387-tdep.o i386-tdep.o i386-common-tdep.o
 TM_FILE= tm-ptx.h
Index: config/i386/ptx4.mt
===================================================================
RCS file: /cvs/src/src/gdb/config/i386/ptx4.mt,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 ptx4.mt
--- config/i386/ptx4.mt	16 Apr 1999 01:34:19 -0000	1.1.1.1
+++ config/i386/ptx4.mt	30 Aug 2002 13:42:51 -0000
@@ -1,3 +1,3 @@
 # Target: Sequent Symmetry running ptx 4.0, with Weitek 1167 or i387.
-TDEPFILES= symm-tdep.o i387-tdep.o i386-tdep.o
+TDEPFILES= symm-tdep.o i387-tdep.o i386-tdep.o i386-common-tdep.o
 TM_FILE= tm-ptx4.h
Index: config/i386/symmetry.mt
===================================================================
RCS file: /cvs/src/src/gdb/config/i386/symmetry.mt,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 symmetry.mt
--- config/i386/symmetry.mt	16 Apr 1999 01:34:19 -0000	1.1.1.1
+++ config/i386/symmetry.mt	30 Aug 2002 13:42:51 -0000
@@ -1,3 +1,3 @@
 # Target: Sequent Symmetry running Dynix 3.0, with Weitek 1167 or i387.
-TDEPFILES= i386-tdep.o symm-tdep.o i387-tdep.o
+TDEPFILES= i386-tdep.o i386-common-tdep.o symm-tdep.o i387-tdep.o
 TM_FILE= tm-symmetry.h
Index: config/i386/vxworks.mt
===================================================================
RCS file: /cvs/src/src/gdb/config/i386/vxworks.mt,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 vxworks.mt
--- config/i386/vxworks.mt	19 Jul 1999 23:28:21 -0000	1.1.1.1
+++ config/i386/vxworks.mt	30 Aug 2002 13:42:51 -0000
@@ -1,3 +1,3 @@
 # Target: i386 running VxWorks
-TDEPFILES= i386-tdep.o i387-tdep.o 
+TDEPFILES= i386-tdep.o i386-common-tdep.o i387-tdep.o 
 TM_FILE= tm-vxworks.h
Index: config/i386/x86-64linux.mt
===================================================================
RCS file: /cvs/src/src/gdb/config/i386/x86-64linux.mt,v
retrieving revision 1.5
diff -u -p -r1.5 x86-64linux.mt
--- config/i386/x86-64linux.mt	1 Jul 2002 22:09:52 -0000	1.5
+++ config/i386/x86-64linux.mt	30 Aug 2002 13:42:51 -0000
@@ -1,6 +1,7 @@
 # Target: AMD x86-64 running GNU/Linux
 TDEPFILES= x86-64-tdep.o x86-64-linux-tdep.o dwarf2cfi.o \
-	solib.o solib-svr4.o solib-legacy.o
+	solib.o solib-svr4.o solib-legacy.o \
+	i386-common-tdep.o
 
 GDB_MULTI_ARCH=GDB_MULTI_ARCH_TM
 

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

[Mark Kettenis]

Andrew Cagney <ac131313@ges.redhat.com> writes:

> MarkK, I believe, is planning on merging much of the i386 and x86-64 
> stuff so that a single GDB would support both -- that would remove the 
> issue.

Isn't going to happen before branching.  My problem is that I don't
have the opportunity to test an x86-64 target.  I might have a go at
integrating bits, but Michal will probably have to test those changes
for me.

> Is there any immediate technical problem stopping x86-64 linking in 
> i386-tdep.c?  (Yes scary, multi-arch).

Well, the very least that should be done is merging
x86_64_gdbarch_init with i386_gdbarch_init.

Mark

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

[Andrew Cagney]

> On Thu, Aug 29, 2002 at 04:57:42PM +0200, Michal Ludvig wrote:
> 
>> Daniel Jacobowitz wrote:
> 
>> >Well, actually, I like it. 
> 
>> 
>> Wow! That's a surprise! :-)))
>> 
> 
>> >Some textual changes and comments:
> 
>> 
>> Thanks, I'm not a native speaker ;-)
>> 
> 
>> >>+  builtin_type_i386_eflags = 
>> >>+    init_flags_type (32 /* EFLAGS_LENGTH */, 
>> >>+    	       "__i386_eflags", (struct objfile *) NULL);
>> >>+  add_flag_name (builtin_type_i386_eflags, 0, "CF");
>> >>+  builtin_type_simd_mxcsr =
>> >>+    init_flags_type (32 /* EFLAGS_LENGTH */,
>> >>+    	       "__simd_mxcsr", (struct objfile *) NULL);
>> >>+  add_flag_name (builtin_type_simd_mxcsr, 0, "IE");
> 
>> > Do these really need to be in common code?  That's gross.  Yes, I know
>> > a whole lot of others are, but those are all floatformats or standard
>> > vectors.
>> > This should be in i386-tdep.c.
> 
>> 
>> I don't compile i386-tdep.c for x86-64. Should I duplicate the code for 
>> x86-64 or better leave it here to have it only once?
> 
> 
> Hmm, there's already some common files between the ports; there should
> be another, I think.  I don't want something as i386-specific as this
> anywhere near gdbtypes.c.  How about i386-common-tdep.c or something
> like that?

It shouldn't be in gdbtypes.c.

MarkK, I believe, is planning on merging much of the i386 and x86-64 
stuff so that a single GDB would support both -- that would remove the 
issue.

Is there any immediate technical problem stopping x86-64 linking in 
i386-tdep.c?  (Yes scary, multi-arch).

Andrew

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

[Daniel Jacobowitz]

On Thu, Aug 29, 2002 at 04:57:42PM +0200, Michal Ludvig wrote:
> Daniel Jacobowitz wrote:
> >Well, actually, I like it. 
> 
> Wow! That's a surprise! :-)))
> 
> >Some textual changes and comments:
> 
> Thanks, I'm not a native speaker ;-)
> 
> >>+  builtin_type_i386_eflags = 
> >>+    init_flags_type (32 /* EFLAGS_LENGTH */, 
> >>+    	       "__i386_eflags", (struct objfile *) NULL);
> >>+  add_flag_name (builtin_type_i386_eflags, 0, "CF");
> >>+  builtin_type_simd_mxcsr =
> >>+    init_flags_type (32 /* EFLAGS_LENGTH */,
> >>+    	       "__simd_mxcsr", (struct objfile *) NULL);
> >>+  add_flag_name (builtin_type_simd_mxcsr, 0, "IE");
> > Do these really need to be in common code?  That's gross.  Yes, I know
> > a whole lot of others are, but those are all floatformats or standard
> > vectors.
> > This should be in i386-tdep.c.
> 
> I don't compile i386-tdep.c for x86-64. Should I duplicate the code for 
> x86-64 or better leave it here to have it only once?

Hmm, there's already some common files between the ports; there should
be another, I think.  I don't want something as i386-specific as this
anywhere near gdbtypes.c.  How about i386-common-tdep.c or something
like that?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

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

[Michal Ludvig]

Daniel Jacobowitz wrote:
> Well, actually, I like it. 

Wow! That's a surprise! :-)))

> Some textual changes and comments:

Thanks, I'm not a native speaker ;-)

>>+  builtin_type_i386_eflags = 
>>+    init_flags_type (32 /* EFLAGS_LENGTH */, 
>>+    	       "__i386_eflags", (struct objfile *) NULL);
>>+  add_flag_name (builtin_type_i386_eflags, 0, "CF");
 >>+  builtin_type_simd_mxcsr =
 >>+    init_flags_type (32 /* EFLAGS_LENGTH */,
 >>+    	       "__simd_mxcsr", (struct objfile *) NULL);
 >>+  add_flag_name (builtin_type_simd_mxcsr, 0, "IE");
 > Do these really need to be in common code?  That's gross.  Yes, I know
 > a whole lot of others are, but those are all floatformats or standard
 > vectors.
 > This should be in i386-tdep.c.

I don't compile i386-tdep.c for x86-64. Should I duplicate the code for 
x86-64 or better leave it here to have it only once?

Michal Ludvig
-- 
* SuSE CR, s.r.o     * mludvig@suse.cz
* +420 2 9654 5373   * http://www.suse.cz

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

[Daniel Jacobowitz]

On Thu, Aug 29, 2002 at 03:35:25PM +0200, Michal Ludvig wrote:
> Andrew Cagney wrote:
> >However, given that there are two implementations, I get the feeling 
> >that [possibly fee paying] users want something.
> 
> Here is the reworked patch. The print function was moved to valprint.c 
> and is called from all relevant <language>-valprint.c modules.
> Also I've added support for MXCSR register both for i386 and x86-64.
> 
> Comments? Can I commit it?

Well, actually, I like it.  Some textual changes and comments:

> +/*
> + * - The following three functions are intended to be used for BitFlags 
> + *   types (ie i386's EFLAGS register).

e.g., not ie.

> + * - As a BitFlag we understand an integer where some bits may have 
> + *   a symbolic names that would be printed when the bit is set.

"A BitFlags type is an integer where bits may have a symbolic name to
be printed when the bit is set."

> + * - Printing is done in c_val_print() under a TYPE_CODE_FLAGS label.

<lang>_val_print perhaps?

> + * - Add a symbolic name of relevant bits using add_flag_name() after 
> + *   an initialisation of your type.
> + */

"Add symbolic names for relevant bits using add_flag_name() after
initializing the BitFlags type."

> +struct type *
> +init_flags_type (int bitlength, char *name, struct objfile *objfile)
> +{
> +  register struct type *type;
> +  
> +  type = alloc_type (objfile);
> +  
> +  TYPE_CODE (type) = TYPE_CODE_FLAGS;
> +  TYPE_LENGTH (type) = bitlength / 8 + ( bitlength % 8 ? 1 : 0 );

Don't hardcode a magic eight.  How about:
  (bitlength + TARGET_CHAR_BIT - 1) / TARGET_CHAR_BIT
(I think it's called TARGET_CHAR_BIT at least)

> @@ -2555,6 +2614,8 @@ rank_one_type (struct type *parm, struct
>  	    return INTEGER_PROMOTION_BADNESS;
>  	  else
>  	    return INTEGER_COERCION_BADNESS;
> +        case TYPE_CODE_FLAGS:
> +	  return 0;
>  	case TYPE_CODE_ENUM:
>  	case TYPE_CODE_CHAR:
>  	case TYPE_CODE_RANGE:

No, INTEGER_PROMOTION_BADNESS.  Just add the case, not the return.

> @@ -3433,6 +3497,49 @@ build_gdbtypes (void)
>      init_type (TYPE_CODE_INT, TARGET_BFD_VMA_BIT / 8,
>  	       TYPE_FLAG_UNSIGNED,
>  	       "__bfd_vma", (struct objfile *) NULL);
> +
> +  builtin_type_i386_eflags = 
> +    init_flags_type (32 /* EFLAGS_LENGTH */, 
> +    	       "__i386_eflags", (struct objfile *) NULL);
> +  add_flag_name (builtin_type_i386_eflags, 0, "CF");
> +  add_flag_ignore (builtin_type_i386_eflags, 1);
> +  add_flag_name (builtin_type_i386_eflags, 2, "PF");
> +  add_flag_name (builtin_type_i386_eflags, 4, "AF");
> +  add_flag_name (builtin_type_i386_eflags, 6, "ZF");
> +  add_flag_name (builtin_type_i386_eflags, 7, "SF");
> +  add_flag_name (builtin_type_i386_eflags, 8, "TF");
> +  add_flag_name (builtin_type_i386_eflags, 9, "IF");
> +  add_flag_name (builtin_type_i386_eflags, 10, "DF");
> +  add_flag_name (builtin_type_i386_eflags, 11, "OF");
> +  add_flag_ignore (builtin_type_i386_eflags, 12);
> +  add_flag_ignore (builtin_type_i386_eflags, 13);
> +  add_flag_name (builtin_type_i386_eflags, 14, "NT");
> +  add_flag_name (builtin_type_i386_eflags, 16, "RF");
> +  add_flag_name (builtin_type_i386_eflags, 17, "VM");
> +  add_flag_name (builtin_type_i386_eflags, 18, "AC");
> +  add_flag_name (builtin_type_i386_eflags, 19, "VIF");
> +  add_flag_name (builtin_type_i386_eflags, 20, "VIP");
> +  add_flag_name (builtin_type_i386_eflags, 21, "ID");
> +  
> +  builtin_type_simd_mxcsr = 
> +    init_flags_type (32 /* EFLAGS_LENGTH */, 
> +    	       "__simd_mxcsr", (struct objfile *) NULL);
> +  add_flag_name (builtin_type_simd_mxcsr, 0, "IE");
> +  add_flag_name (builtin_type_simd_mxcsr, 1, "DE");
> +  add_flag_name (builtin_type_simd_mxcsr, 2, "ZE");
> +  add_flag_name (builtin_type_simd_mxcsr, 3, "OE");
> +  add_flag_name (builtin_type_simd_mxcsr, 4, "UE");
> +  add_flag_name (builtin_type_simd_mxcsr, 5, "PE");
> +  add_flag_name (builtin_type_simd_mxcsr, 6, "DAZ");
> +  add_flag_name (builtin_type_simd_mxcsr, 7, "IM");
> +  add_flag_name (builtin_type_simd_mxcsr, 8, "DM");
> +  add_flag_name (builtin_type_simd_mxcsr, 9, "ZM");
> +  add_flag_name (builtin_type_simd_mxcsr, 10, "OM");
> +  add_flag_name (builtin_type_simd_mxcsr, 11, "UM");
> +  add_flag_name (builtin_type_simd_mxcsr, 12, "PM");
> +  add_flag_name (builtin_type_simd_mxcsr, 13, "RC1");
> +  add_flag_name (builtin_type_simd_mxcsr, 14, "RC2");
> +  add_flag_name (builtin_type_simd_mxcsr, 15, "FZ");
>  }
>  
>  

Do these really need to be in common code?  That's gross.  Yes, I know
a whole lot of others are, but those are all floatformats or standard
vectors.

This should be in i386-tdep.c.

> @@ -926,6 +927,10 @@ extern struct type *builtin_type_void_fu
>  
>  /* The target CPU's address type.  This is the ISA address size. */
>  extern struct type *builtin_type_CORE_ADDR;
> +
> +/* Type for i386 EFLAGS register.  */
> +extern struct type *builtin_type_i386_eflags;
> +
>  /* The symbol table address type.  Some object file formats have a 32
>     bit address type even though the TARGET has a 64 bit pointer type
>     (cf MIPS). */
> @@ -951,6 +956,9 @@ extern struct type *builtin_type_v8qi;
>  extern struct type *builtin_type_v8hi;
>  extern struct type *builtin_type_v4hi;
>  extern struct type *builtin_type_v2si;
> +
> +/* MXCSR SIMD control register.  */
> +extern struct type *builtin_type_simd_mxcsr;
>  
>  /* Type for 64 bit vectors. */
>  extern struct type *builtin_type_vec64;

Ditto.


The rest of it looks good to me.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

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

[Michal Ludvig]

[-- Attachment #1: Type: text/plain, Size: 477 bytes --]

Andrew Cagney wrote:
> However, given that there are two implementations, I get the feeling 
> that [possibly fee paying] users want something.

Here is the reworked patch. The print function was moved to valprint.c 
and is called from all relevant <language>-valprint.c modules.
Also I've added support for MXCSR register both for i386 and x86-64.

Comments? Can I commit it?

Michal Ludvig
-- 
* SuSE CR, s.r.o     * mludvig@suse.cz
* +420 2 9654 5373   * http://www.suse.cz

[-- Attachment #2: flags-3.diff --]
[-- Type: text/plain, Size: 16343 bytes --]

2002-08-29  Michal Ludvig  <mludvig@suse.cz>

	* gdbtypes.c (builtin_type_i386_eflags): Added.
	(builtin_type_simd_mxcsr): Added.
	(add_flag_ignore, add_flag_name, init_flags_type): Added.
	(is_integral_type, rank_one_type, recursive_dump_type): Added
	TYPE_CODE_FLAGS handling.
	(build_gdbtypes): Added builtin_type_i386_eflags and 
	builtin_type_simd_mxcsr initialization.
	* gdbtypes.h (type_code): Added TYPE_CODE_FLAGS.
	(builtin_type_i386_eflags): Added.
	(builtin_type_simd_mxcsr): Added.
	* valprint.c (val_print_type_code_flags): Added.
	* valprint.h (val_print_type_code_flags): Added.
	* values.c (unpack_long): Added TYPE_CODE_FLAGS handling.
	* i386-tdep.c (i386_register_virtual_type): Added eflags and 
	mxcsr registers handling.
	* x86-64-tdep.c (x86_64_register_info_table): Changed type 
	of eflags and mxcsr registers.
	* ada-valprint.c (ada_val_print_1): Added TYPE_CODE_FLAGS case.
	* c-valprint.c (c_val_print): Ditto.
	* f-valprint.c (f_val_print): Ditto.
	* jv-valprint.c (java_val_print): Ditto.
	* p-valprint.c (pascal_val_print): Ditto.

	
Index: gdbtypes.c
===================================================================
RCS file: /cvs/src/src/gdb/gdbtypes.c,v
retrieving revision 1.56
diff -u -p -r1.56 gdbtypes.c
--- gdbtypes.c	20 Aug 2002 19:57:32 -0000	1.56
+++ gdbtypes.c	29 Aug 2002 13:08:13 -0000
@@ -116,6 +116,8 @@ struct type *builtin_type_void_data_ptr;
 struct type *builtin_type_void_func_ptr;
 struct type *builtin_type_CORE_ADDR;
 struct type *builtin_type_bfd_vma;
+struct type *builtin_type_i386_eflags;
+struct type *builtin_type_simd_mxcsr;
 
 int opaque_type_resolution = 1;
 int overload_debug = 0;
@@ -782,6 +784,61 @@ create_set_type (struct type *result_typ
   return (result_type);
 }
 
+/*
+ * - The following three functions are intended to be used for BitFlags 
+ *   types (ie i386's EFLAGS register).
+ * - As a BitFlag we understand an integer where some bits may have 
+ *   a symbolic names that would be printed when the bit is set.
+ * - Printing is done in c_val_print() under a TYPE_CODE_FLAGS label.
+ * - Add a symbolic name of relevant bits using add_flag_name() after 
+ *   an initialisation of your type.
+ */
+void
+add_flag_ignore (struct type *type, int bitpos)
+{
+	TYPE_FIELD_BITPOS (type, bitpos) = -1;
+}
+
+void
+add_flag_name (struct type *type, int bitpos, char *name)
+{
+	int namelen;
+	
+	gdb_assert (TYPE_CODE (type) == TYPE_CODE_FLAGS);
+	gdb_assert (bitpos < TYPE_NFIELDS (type));
+	gdb_assert (bitpos >= 0);
+	
+	namelen=strlen(name)+1;
+	TYPE_FIELD_NAME (type, bitpos) = xmalloc (namelen);
+	snprintf(TYPE_FIELD_NAME (type, bitpos), namelen, "%s", name);	
+
+	TYPE_FIELD_BITPOS (type, bitpos) = bitpos;
+}
+
+struct type *
+init_flags_type (int bitlength, char *name, struct objfile *objfile)
+{
+  register struct type *type;
+  
+  type = alloc_type (objfile);
+  
+  TYPE_CODE (type) = TYPE_CODE_FLAGS;
+  TYPE_LENGTH (type) = bitlength / 8 + ( bitlength % 8 ? 1 : 0 );
+  TYPE_FLAGS (type) = TYPE_FLAG_UNSIGNED;
+  TYPE_NFIELDS (type) = bitlength;
+  TYPE_FIELDS (type) = (struct field *)
+    TYPE_ALLOC (type, bitlength * sizeof (struct field));
+  memset (TYPE_FIELDS (type), 0, sizeof (struct field));
+
+  if ((name != NULL) && (objfile != NULL))
+      TYPE_NAME (type) =
+	obsavestring (name, strlen (name), &objfile->type_obstack);
+  else
+      TYPE_NAME (type) = name;
+  
+  return (type);
+}
+
 /* Construct and return a type of the form:
 	struct NAME { ELT_TYPE ELT_NAME[N]; }
    We use these types for SIMD registers.  For example, the type of
@@ -1946,6 +2003,7 @@ is_integral_type (struct type *t)
   return
     ((t != NULL)
      && ((TYPE_CODE (t) == TYPE_CODE_INT)
+	 || (TYPE_CODE (t) == TYPE_CODE_FLAGS)
 	 || (TYPE_CODE (t) == TYPE_CODE_ENUM)
 	 || (TYPE_CODE (t) == TYPE_CODE_CHAR)
 	 || (TYPE_CODE (t) == TYPE_CODE_RANGE)
@@ -2479,6 +2537,7 @@ rank_one_type (struct type *parm, struct
 	case TYPE_CODE_FUNC:
 	  return rank_one_type (TYPE_TARGET_TYPE (parm), arg);
 	case TYPE_CODE_INT:
+	case TYPE_CODE_FLAGS:
 	case TYPE_CODE_ENUM:
 	case TYPE_CODE_CHAR:
 	case TYPE_CODE_RANGE:
@@ -2555,6 +2614,8 @@ rank_one_type (struct type *parm, struct
 	    return INTEGER_PROMOTION_BADNESS;
 	  else
 	    return INTEGER_COERCION_BADNESS;
+        case TYPE_CODE_FLAGS:
+	  return 0;
 	case TYPE_CODE_ENUM:
 	case TYPE_CODE_CHAR:
 	case TYPE_CODE_RANGE:
@@ -3000,6 +3061,9 @@ recursive_dump_type (struct type *type, 
     case TYPE_CODE_INT:
       printf_filtered ("(TYPE_CODE_INT)");
       break;
+    case TYPE_CODE_FLAGS:
+      printf_filtered ("(TYPE_CODE_FLAGS)");
+      break;
     case TYPE_CODE_FLT:
       printf_filtered ("(TYPE_CODE_FLT)");
       break;
@@ -3433,6 +3497,49 @@ build_gdbtypes (void)
     init_type (TYPE_CODE_INT, TARGET_BFD_VMA_BIT / 8,
 	       TYPE_FLAG_UNSIGNED,
 	       "__bfd_vma", (struct objfile *) NULL);
+
+  builtin_type_i386_eflags = 
+    init_flags_type (32 /* EFLAGS_LENGTH */, 
+    	       "__i386_eflags", (struct objfile *) NULL);
+  add_flag_name (builtin_type_i386_eflags, 0, "CF");
+  add_flag_ignore (builtin_type_i386_eflags, 1);
+  add_flag_name (builtin_type_i386_eflags, 2, "PF");
+  add_flag_name (builtin_type_i386_eflags, 4, "AF");
+  add_flag_name (builtin_type_i386_eflags, 6, "ZF");
+  add_flag_name (builtin_type_i386_eflags, 7, "SF");
+  add_flag_name (builtin_type_i386_eflags, 8, "TF");
+  add_flag_name (builtin_type_i386_eflags, 9, "IF");
+  add_flag_name (builtin_type_i386_eflags, 10, "DF");
+  add_flag_name (builtin_type_i386_eflags, 11, "OF");
+  add_flag_ignore (builtin_type_i386_eflags, 12);
+  add_flag_ignore (builtin_type_i386_eflags, 13);
+  add_flag_name (builtin_type_i386_eflags, 14, "NT");
+  add_flag_name (builtin_type_i386_eflags, 16, "RF");
+  add_flag_name (builtin_type_i386_eflags, 17, "VM");
+  add_flag_name (builtin_type_i386_eflags, 18, "AC");
+  add_flag_name (builtin_type_i386_eflags, 19, "VIF");
+  add_flag_name (builtin_type_i386_eflags, 20, "VIP");
+  add_flag_name (builtin_type_i386_eflags, 21, "ID");
+  
+  builtin_type_simd_mxcsr = 
+    init_flags_type (32 /* EFLAGS_LENGTH */, 
+    	       "__simd_mxcsr", (struct objfile *) NULL);
+  add_flag_name (builtin_type_simd_mxcsr, 0, "IE");
+  add_flag_name (builtin_type_simd_mxcsr, 1, "DE");
+  add_flag_name (builtin_type_simd_mxcsr, 2, "ZE");
+  add_flag_name (builtin_type_simd_mxcsr, 3, "OE");
+  add_flag_name (builtin_type_simd_mxcsr, 4, "UE");
+  add_flag_name (builtin_type_simd_mxcsr, 5, "PE");
+  add_flag_name (builtin_type_simd_mxcsr, 6, "DAZ");
+  add_flag_name (builtin_type_simd_mxcsr, 7, "IM");
+  add_flag_name (builtin_type_simd_mxcsr, 8, "DM");
+  add_flag_name (builtin_type_simd_mxcsr, 9, "ZM");
+  add_flag_name (builtin_type_simd_mxcsr, 10, "OM");
+  add_flag_name (builtin_type_simd_mxcsr, 11, "UM");
+  add_flag_name (builtin_type_simd_mxcsr, 12, "PM");
+  add_flag_name (builtin_type_simd_mxcsr, 13, "RC1");
+  add_flag_name (builtin_type_simd_mxcsr, 14, "RC2");
+  add_flag_name (builtin_type_simd_mxcsr, 15, "FZ");
 }
 
 
Index: gdbtypes.h
===================================================================
RCS file: /cvs/src/src/gdb/gdbtypes.h,v
retrieving revision 1.35
diff -u -p -r1.35 gdbtypes.h
--- gdbtypes.h	10 Aug 2002 05:12:40 -0000	1.35
+++ gdbtypes.h	29 Aug 2002 13:08:13 -0000
@@ -85,6 +85,7 @@ enum type_code
     TYPE_CODE_ENUM,		/* Enumeration type */
     TYPE_CODE_FUNC,		/* Function type */
     TYPE_CODE_INT,		/* Integer type */
+    TYPE_CODE_FLAGS,		/* BitFlags type */
 
     /* Floating type.  This is *NOT* a complex type.  Beware, there are parts
        of GDB which bogusly assume that TYPE_CODE_FLT can mean complex.  */
@@ -926,6 +927,10 @@ extern struct type *builtin_type_void_fu
 
 /* The target CPU's address type.  This is the ISA address size. */
 extern struct type *builtin_type_CORE_ADDR;
+
+/* Type for i386 EFLAGS register.  */
+extern struct type *builtin_type_i386_eflags;
+
 /* The symbol table address type.  Some object file formats have a 32
    bit address type even though the TARGET has a 64 bit pointer type
    (cf MIPS). */
@@ -951,6 +956,9 @@ extern struct type *builtin_type_v8qi;
 extern struct type *builtin_type_v8hi;
 extern struct type *builtin_type_v4hi;
 extern struct type *builtin_type_v2si;
+
+/* MXCSR SIMD control register.  */
+extern struct type *builtin_type_simd_mxcsr;
 
 /* Type for 64 bit vectors. */
 extern struct type *builtin_type_vec64;
Index: valprint.c
===================================================================
RCS file: /cvs/src/src/gdb/valprint.c,v
retrieving revision 1.28
diff -u -p -r1.28 valprint.c
--- valprint.c	24 Aug 2002 00:40:59 -0000	1.28
+++ valprint.c	29 Aug 2002 13:08:14 -0000
@@ -1183,6 +1183,39 @@ val_print_string (CORE_ADDR addr, int le
 }
 \f
 
+void
+val_print_type_code_flags (char *valaddr, struct type *type, 
+		           int format, int size, 
+			   struct ui_file *stream)
+{
+  unsigned int len;
+  int i;
+  LONGEST val;
+  
+  if (format)
+    print_scalar_formatted (valaddr, type, format, 0, stream);
+  else
+  {
+    len = TYPE_NFIELDS (type);
+    val = unpack_long (type, valaddr);
+    fputs_filtered("[", stream);
+    for (i = len-1; i >= 0; i--)
+      {
+        QUIT;
+        if (TYPE_FIELD_BITPOS (type, i) != -1 && val & (1 << i))
+        if (val & (1 << i))
+        {
+      	if(TYPE_FIELD_NAME (type, i))
+            fprintf_filtered (stream, " %s", TYPE_FIELD_NAME (type, i));
+      	else
+            fprintf_filtered (stream, " #%d", i);
+      			  
+        }
+      }
+    fputs_filtered(" ]", stream);
+  }
+}
+
 /* Validate an input or output radix setting, and make sure the user
    knows what they really did here.  Radix setting is confusing, e.g.
    setting the input radix to "10" never changes it!  */
Index: valprint.h
===================================================================
RCS file: /cvs/src/src/gdb/valprint.h,v
retrieving revision 1.3
diff -u -p -r1.3 valprint.h
--- valprint.h	21 Oct 2001 19:20:30 -0000	1.3
+++ valprint.h	29 Aug 2002 13:08:14 -0000
@@ -49,6 +49,10 @@ extern void val_print_array_elements (st
 extern void val_print_type_code_int (struct type *, char *,
 				     struct ui_file *);
 
+extern void val_print_type_code_flags (char *valaddr, struct type *type, 
+				       int format, int size, 
+				       struct ui_file *stream);
+
 extern void print_binary_chars (struct ui_file *, unsigned char *,
 				unsigned int);
 
Index: values.c
===================================================================
RCS file: /cvs/src/src/gdb/values.c,v
retrieving revision 1.40
diff -u -p -r1.40 values.c
--- values.c	24 Aug 2002 00:21:35 -0000	1.40
+++ values.c	29 Aug 2002 13:08:14 -0000
@@ -696,6 +696,7 @@ unpack_long (struct type *type, char *va
     case TYPE_CODE_ENUM:
     case TYPE_CODE_BOOL:
     case TYPE_CODE_INT:
+    case TYPE_CODE_FLAGS:
     case TYPE_CODE_CHAR:
     case TYPE_CODE_RANGE:
       if (nosign)
Index: i386-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/i386-tdep.c,v
retrieving revision 1.85
diff -u -p -r1.85 i386-tdep.c
--- i386-tdep.c	26 Aug 2002 18:35:25 -0000	1.85
+++ i386-tdep.c	29 Aug 2002 13:08:13 -0000
@@ -1102,6 +1102,12 @@ 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 (regnum == MXCSR_REGNUM)
+    return builtin_type_simd_mxcsr;
+
   if (IS_FP_REGNUM (regnum))
     return builtin_type_i387_ext;
 
Index: x86-64-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/x86-64-tdep.c,v
retrieving revision 1.26
diff -u -p -r1.26 x86-64-tdep.c
--- x86-64-tdep.c	24 Aug 2002 00:21:35 -0000	1.26
+++ x86-64-tdep.c	29 Aug 2002 13:08:14 -0000
@@ -68,7 +68,7 @@ static struct register_info x86_64_regis
   /* 14 */ {8, "r14", &builtin_type_int64},
   /* 15 */ {8, "r15", &builtin_type_int64},
   /* 16 */ {8, "rip", &builtin_type_void_func_ptr},
-  /* 17 */ {4, "eflags", &builtin_type_int32},
+  /* 17 */ {4, "eflags", &builtin_type_i386_eflags},
   /* 18 */ {4, "ds", &builtin_type_int32},
   /* 19 */ {4, "es", &builtin_type_int32},
   /* 20 */ {4, "fs", &builtin_type_int32},
@@ -105,7 +105,7 @@ static struct register_info x86_64_regis
   /* 51 */ {16, "xmm13", &builtin_type_v4sf},
   /* 52 */ {16, "xmm14", &builtin_type_v4sf},
   /* 53 */ {16, "xmm15", &builtin_type_v4sf},
-  /* 54 */ {4, "mxcsr", &builtin_type_int32}
+  /* 54 */ {4, "mxcsr", &builtin_type_simd_mxcsr}
 };
 
 /* This array is a mapping from Dwarf-2 register 
Index: ada-valprint.c
===================================================================
RCS file: /cvs/src/src/gdb/ada-valprint.c,v
retrieving revision 1.4
diff -u -p -r1.4 ada-valprint.c
--- ada-valprint.c	18 Aug 2002 18:07:33 -0000	1.4
+++ ada-valprint.c	29 Aug 2002 13:08:12 -0000
@@ -777,6 +777,11 @@ ada_val_print_1 (struct type *type, char
 	    fputs_filtered ("???", stream);
 	}
       break;
+
+    case TYPE_CODE_FLAGS:
+      val_print_type_code_flags (valaddr + embedded_offset, type, 
+		                 format, 0, stream);
+      break;
     }
   return 0;
 }
Index: c-valprint.c
===================================================================
RCS file: /cvs/src/src/gdb/c-valprint.c,v
retrieving revision 1.14
diff -u -p -r1.14 c-valprint.c
--- c-valprint.c	27 Aug 2002 22:37:06 -0000	1.14
+++ c-valprint.c	29 Aug 2002 13:08:12 -0000
@@ -486,6 +486,11 @@ c_val_print (struct type *type, char *va
       fprintf_filtered (stream, " * I");
       break;
 
+    case TYPE_CODE_FLAGS:
+      val_print_type_code_flags (valaddr + embedded_offset, type, 
+		                 format, 0, stream);
+      break;
+
     default:
       error ("Invalid C/C++ type code %d in symbol table.", TYPE_CODE (type));
     }
Index: f-valprint.c
===================================================================
RCS file: /cvs/src/src/gdb/f-valprint.c,v
retrieving revision 1.6
diff -u -p -r1.6 f-valprint.c
--- f-valprint.c	7 Mar 2001 02:57:08 -0000	1.6
+++ f-valprint.c	29 Aug 2002 13:08:13 -0000
@@ -544,6 +544,11 @@ f_val_print (struct type *type, char *va
       fprintf_filtered (stream, "<incomplete type>");
       break;
 
+    case TYPE_CODE_FLAGS:
+      val_print_type_code_flags (valaddr + embedded_offset, type, 
+		                 format, 0, stream);
+      break;
+
     default:
       error ("Invalid F77 type code %d in symbol table.", TYPE_CODE (type));
     }
Index: jv-valprint.c
===================================================================
RCS file: /cvs/src/src/gdb/jv-valprint.c,v
retrieving revision 1.11
diff -u -p -r1.11 jv-valprint.c
--- jv-valprint.c	27 Aug 2002 22:37:06 -0000	1.11
+++ jv-valprint.c	29 Aug 2002 13:08:13 -0000
@@ -518,6 +518,11 @@ java_val_print (struct type *type, char 
 			       recurse, pretty);
       break;
 
+    case TYPE_CODE_FLAGS:
+      val_print_type_code_flags (valaddr + embedded_offset, type, 
+		                 format, 0, stream);
+      break;
+
     default:
       return c_val_print (type, valaddr, embedded_offset, address, stream,
 			  format, deref_ref, recurse, pretty);
Index: p-valprint.c
===================================================================
RCS file: /cvs/src/src/gdb/p-valprint.c,v
retrieving revision 1.13
diff -u -p -r1.13 p-valprint.c
--- p-valprint.c	19 Aug 2002 13:12:09 -0000	1.13
+++ p-valprint.c	29 Aug 2002 13:08:13 -0000
@@ -524,6 +524,11 @@ pascal_val_print (struct type *type, cha
       fprintf_filtered (stream, "<incomplete type>");
       break;
 
+    case TYPE_CODE_FLAGS:
+      val_print_type_code_flags (valaddr + embedded_offset, type, 
+		                 format, 0, stream);
+      break;
+
     default:
       error ("Invalid pascal type code %d in symbol table.", TYPE_CODE (type));
     }

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

[Andrew Cagney]

> On Wed, Aug 28, 2002 at 04:42:00PM +0200, Michal Ludvig wrote:
> 
>> Andrew Cagney wrote:
> 
>> >Attatched is an old and related patch I've dug out of an old branch of 
>> >GDB that Red Hat was providing for a customer.
> 
>> 
>> The mine one is more generic I think, and while it adds new TYPE_CODE it 
>> can be used for other purposes as well (IIRC recently someone committed 
>> a patch that depended on this type code but had to revert it).
>> 
>> I'm afraid people don't know how to use the complex, nested 
>> TYPE_CODE_SET, while the usage of TYPE_CODE_FLAGS is pretty simple.
>> If would change it so that it isn't c-specific, but rather language 
>> independent, would you consider approval? Other things (eg. length of 
>> the flagword) aren't IMHO that important for now.
> 
> 
> But Andrew's patch doesn't require a new infrastructure, which is nice. 
> I stand by all my previous objections to your patch.  We have a type
> that does this; fix its complex, nested interface, then!  Don't add
> more type codes.

It's er, not really my patch :-)  The original code is Fernando's.   I'm 
as they say, the messenger here.

I actually think someone should try both patches side by side and see 
which one works better when used in anger.  I also suspect, like with 
vectors, a little register display customization will occure.

Andrew

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

[Michal Ludvig]

Daniel Jacobowitz wrote:
> But Andrew's patch doesn't require a new infrastructure, which is nice. 
> I stand by all my previous objections to your patch.  We have a type
> that does this

No, it does something else and perhaps it could be tweaked to do what I 
need.

 > fix its complex, nested interface, then!

I believe FLAGS would be in use more often then SET. Why to "rape" SET 
everytime when I'd need it to behave like FLAGS? It's much clearer to 
have FLAGS type for flags puropses.

Michal Ludvig
-- 
* SuSE CR, s.r.o     * mludvig@suse.cz
* +420 2 9654 5373   * http://www.suse.cz

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

[Daniel Jacobowitz]

On Wed, Aug 28, 2002 at 04:42:00PM +0200, Michal Ludvig wrote:
> Andrew Cagney wrote:
> >Attatched is an old and related patch I've dug out of an old branch of 
> >GDB that Red Hat was providing for a customer.
> 
> The mine one is more generic I think, and while it adds new TYPE_CODE it 
> can be used for other purposes as well (IIRC recently someone committed 
> a patch that depended on this type code but had to revert it).
> 
> I'm afraid people don't know how to use the complex, nested 
> TYPE_CODE_SET, while the usage of TYPE_CODE_FLAGS is pretty simple.
> If would change it so that it isn't c-specific, but rather language 
> independent, would you consider approval? Other things (eg. length of 
> the flagword) aren't IMHO that important for now.

But Andrew's patch doesn't require a new infrastructure, which is nice. 
I stand by all my previous objections to your patch.  We have a type
that does this; fix its complex, nested interface, then!  Don't add
more type codes.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

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

[Michal Ludvig]

Andrew Cagney wrote:
> Attatched is an old and related patch I've dug out of an old branch of 
> GDB that Red Hat was providing for a customer.

The mine one is more generic I think, and while it adds new TYPE_CODE it 
can be used for other purposes as well (IIRC recently someone committed 
a patch that depended on this type code but had to revert it).

I'm afraid people don't know how to use the complex, nested 
TYPE_CODE_SET, while the usage of TYPE_CODE_FLAGS is pretty simple.
If would change it so that it isn't c-specific, but rather language 
independent, would you consider approval? Other things (eg. length of 
the flagword) aren't IMHO that important for now.

Michal Ludvig
-- 
* SuSE CR, s.r.o     * mludvig@suse.cz
* +420 2 9654 5373   * http://www.suse.cz

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

[Andrew Cagney]

[-- Attachment #1: Type: text/plain, Size: 833 bytes --]

Attatched is an old and related patch I've dug out of an old branch of 
GDB that Red Hat was providing for a customer.

I don't actually care what the type of eflags ends up being (the 
attached looks like):

(top-gdb) info registers
....
eflags         {eflags = 0x216, bits = {ID = 0x0, VIP = 0x0, VIF = 0x0,
     AC = 0x0, VM = 0x0, RF = 0x0, NT = 0x0, IOPL = 0x0, OF = 0x0, DF = 
0x0,
     IF = 0x1, TF = 0x0, SF = 0x0, ZF = 0x0, AF = 0x1, PF = 0x1,
     CF = 0x0}}  {eflags = 534, bits = {ID = 0, VIP = 0, VIF = 0, AC = 0,
     VM = 0, RF = 0, NT = 0, IOPL = 0, OF = 0, DF = 0, IF = 1, TF = 0, 
SF = 0,
     ZF = 0, AF = 1, PF = 1, CF = 0}}

However, given that there are two implementations, I get the feeling 
that [possibly fee paying] users want something.

Andrew

(that reminds me, ``AC'' et.al. should be in lower case).

[-- Attachment #2: diffs --]
[-- Type: text/plain, Size: 6430 bytes --]

2002-08-27  Andrew Cagney  <cagney@redhat.com>

	* i386-tdep.h (EFLAGS_REGNUM): Define.
	* i386-tdep.c (builtin_type_i386_eflags): New function.  Based on
	code by Fernando Nasser.
	(i386_register_virtual_type): Return builtin_type_i386_eflags when
	EFLAGS_REGNUM.

Index: i386-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/i386-tdep.c,v
retrieving revision 1.83
diff -u -r1.83 i386-tdep.c
--- i386-tdep.c	23 Aug 2002 19:26:14 -0000	1.83
+++ i386-tdep.c	27 Aug 2002 19:06:18 -0000
@@ -1090,6 +1090,174 @@
 					type);
 }
 \f
+/* Construct some standard GDB types.  */
+
+static struct type *
+builtin_type_i386_eflags (void)
+{
+  /* Construct a type for the EFLAGS register.  The type we're
+     building is this: */
+#if 0     
+  union builtin_type_i386_eflags
+  {
+    int32_t eflags;
+    struct __builtin_i386_eflags_bits
+    {
+      /* We skip the 10 reserved bits here.  */
+      unsigned ID:1;
+      unsigned VIP:1;
+      unsigned VIF:1;
+      unsigned AC:1;
+      unsigned VM:1;
+      unsigned RF:1;
+      /* We skip one reserved bit here.  */
+      unsigned NT:1;
+      unsigned IOPL:2;
+      unsigned OF:1;
+      unsigned DF:1;
+      unsigned IF:1;
+      unsigned TF:1;
+      unsigned SF:1;
+      unsigned ZF:1;
+      /* We skip one reserved bit here.  */
+      unsigned AF:1;
+      /* We skip one reserved bit here.  */
+      unsigned PF:1;
+      /* We skip one reserved bit here.  */
+      unsigned CF:1;
+    } bits;
+  };
+#endif
+  /* Note that we cannot create a structure like that in C because we
+     could not skip the reserved bits and the order would be the
+     reverse of what we want (we want to see bit names from left to
+     right, as in a manual figure).  */
+
+  static struct type *t;	/* The type we are creating. */
+  struct type *tp;	/* The type of the pointer part. */
+  struct type *tb;	/* The type of the bitfields part. */
+  struct field *fu;	/* Fields of the union. */
+  struct field *fs;	/* Fields of the struct. */
+
+  if (t != NULL)
+    return t;
+
+  /* Create fields for each group of bits. */
+  fs = (struct field *) xmalloc (sizeof (*fs) * 17);
+  memset (fs, 0, sizeof (*fs) * 17);
+
+  /* Note that we reverse the order of the fields so they are printed
+     as we would see then in a manual figure, left to right. */
+
+  FIELD_TYPE (fs[16]) = builtin_type_unsigned_int;
+  FIELD_NAME (fs[16]) = "CF";
+  FIELD_BITPOS (fs[16]) = 0;
+  FIELD_BITSIZE (fs[16]) = 1;
+
+  FIELD_TYPE (fs[15]) = builtin_type_unsigned_int;
+  FIELD_NAME (fs[15]) = "PF";
+  FIELD_BITPOS (fs[15]) = 2;
+  FIELD_BITSIZE (fs[15]) = 1;
+
+  FIELD_TYPE (fs[14]) = builtin_type_unsigned_int;
+  FIELD_NAME (fs[14]) = "AF";
+  FIELD_BITPOS (fs[14]) = 4;
+  FIELD_BITSIZE (fs[14]) = 1;
+
+  FIELD_TYPE (fs[13]) = builtin_type_unsigned_int;
+  FIELD_NAME (fs[13]) = "ZF";
+  FIELD_BITPOS (fs[13]) = 6;
+  FIELD_BITSIZE (fs[13]) = 1;
+
+  FIELD_TYPE (fs[12]) = builtin_type_unsigned_int;
+  FIELD_NAME (fs[12]) = "SF";
+  FIELD_BITPOS (fs[12]) = 7;
+  FIELD_BITSIZE (fs[12]) = 1;
+
+  FIELD_TYPE (fs[11]) = builtin_type_unsigned_int;
+  FIELD_NAME (fs[11]) = "TF";
+  FIELD_BITPOS (fs[11]) = 8;
+  FIELD_BITSIZE (fs[11]) = 1;
+
+  FIELD_TYPE (fs[10]) = builtin_type_unsigned_int;
+  FIELD_NAME (fs[10]) = "IF";
+  FIELD_BITPOS (fs[10]) = 9;
+  FIELD_BITSIZE (fs[10]) = 1;
+
+  FIELD_TYPE (fs[9]) = builtin_type_unsigned_int;
+  FIELD_NAME (fs[9]) = "DF";
+  FIELD_BITPOS (fs[9]) = 10;
+  FIELD_BITSIZE (fs[9]) = 1;
+
+  FIELD_TYPE (fs[8]) = builtin_type_unsigned_int;
+  FIELD_NAME (fs[8]) = "OF";
+  FIELD_BITPOS (fs[8]) = 11;
+  FIELD_BITSIZE (fs[8]) = 1;
+
+  FIELD_TYPE (fs[7]) = builtin_type_unsigned_int;
+  FIELD_NAME (fs[7]) = "IOPL";
+  FIELD_BITPOS (fs[7]) = 12;
+  FIELD_BITSIZE (fs[7]) = 2;
+
+  FIELD_TYPE (fs[6]) = builtin_type_unsigned_int;
+  FIELD_NAME (fs[6]) = "NT";
+  FIELD_BITPOS (fs[6]) = 14;
+  FIELD_BITSIZE (fs[6]) = 1;
+
+  FIELD_TYPE (fs[5]) = builtin_type_unsigned_int;
+  FIELD_NAME (fs[5]) = "RF";
+  FIELD_BITPOS (fs[5]) = 16;
+  FIELD_BITSIZE (fs[5]) = 1;
+
+  FIELD_TYPE (fs[4]) = builtin_type_unsigned_int;
+  FIELD_NAME (fs[4]) = "VM";
+  FIELD_BITPOS (fs[4]) = 17;
+  FIELD_BITSIZE (fs[4]) = 1;
+
+  FIELD_TYPE (fs[3]) = builtin_type_unsigned_int;
+  FIELD_NAME (fs[3]) = "AC";
+  FIELD_BITPOS (fs[3]) = 18;
+  FIELD_BITSIZE (fs[3]) = 1;
+
+  FIELD_TYPE (fs[2]) = builtin_type_unsigned_int;
+  FIELD_NAME (fs[2]) = "VIF";
+  FIELD_BITPOS (fs[2]) = 19;
+  FIELD_BITSIZE (fs[2]) = 1;
+
+  FIELD_TYPE (fs[1]) = builtin_type_unsigned_int;
+  FIELD_NAME (fs[1]) = "VIP";
+  FIELD_BITPOS (fs[1]) = 20;
+  FIELD_BITSIZE (fs[1]) = 1;
+
+  FIELD_TYPE (fs[0]) = builtin_type_unsigned_int;
+  FIELD_NAME (fs[0]) = "ID";
+  FIELD_BITPOS (fs[0]) = 21;
+  FIELD_BITSIZE (fs[0]) = 1;
+
+  /* Build a struct type with these bitfields.  */
+  tb = init_type (TYPE_CODE_STRUCT, 4, 0, 0, 0);
+  TYPE_NFIELDS (tb) = 17;
+  TYPE_FIELDS (tb) = fs;
+  TYPE_TAG_NAME (tb) = "builtin_type_i386_eflags_bits";
+
+  /* Now make our type as the union of the pointer and the bitfield parts. */
+  fu = (struct field *) xmalloc (sizeof (*fu) * 2);
+  memset (fu, 0, sizeof (*fu) * 2);
+
+  FIELD_TYPE (fu[0]) = builtin_type_int32;
+  FIELD_NAME (fu[0]) = "eflags";
+
+  FIELD_TYPE (fu[1]) = tb;
+  FIELD_NAME (fu[1]) = "bits";
+
+  /* Build a union type with those fields.  */
+  t = init_type (TYPE_CODE_UNION, 4, 0, 0, 0);
+  TYPE_NFIELDS (t) = 2;
+  TYPE_FIELDS (t) = fu;
+  TYPE_TAG_NAME (t) = "builtin_type_i386_eflags";
+
+  return t;
+}
 
 /* Return the GDB type object for the "standard" data type of data in
    register REGNUM.  Perhaps %esi and %edi should go here, but
@@ -1100,6 +1268,9 @@
 {
   if (regnum == PC_REGNUM || regnum == FP_REGNUM || regnum == SP_REGNUM)
     return lookup_pointer_type (builtin_type_void);
+
+  if (regnum == EFLAGS_REGNUM)
+    return builtin_type_i386_eflags ();
 
   if (IS_FP_REGNUM (regnum))
     return builtin_type_i387_ext;
Index: i386-tdep.h
===================================================================
RCS file: /cvs/src/src/gdb/i386-tdep.h,v
retrieving revision 1.13
diff -u -r1.13 i386-tdep.h
--- i386-tdep.h	20 Aug 2002 17:59:50 -0000	1.13
+++ i386-tdep.h	27 Aug 2002 19:06:18 -0000
@@ -77,6 +77,9 @@
   int sc_sp_offset;
 };
 
+/* The EFLAGS register.  */
+enum { EFLAGS_REGNUM = 9 };
+
 /* Floating-point registers.  */
 
 #define FPU_REG_RAW_SIZE 10

[-- Attachment #3: mailbox-message://ac131313@movemail/fsf/gdb/patches/pending#139828 --]
[-- Type: message/rfc822, Size: 12708 bytes --]

[-- Attachment #3.1.1: Type: text/plain, Size: 1482 bytes --]

(Once again, now with Changelog :-)

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?)

2002-04-22  Michal Ludvig  <mludvig@suse.cz>

         * c-valprint.c (c_val_print): Added handling of TYPE_CODE_FLAGS.
         * gdbtypes.c (builtin_type_i386_eflags): Added.
         (add_flag_ignore, add_flag_name, init_flags_type): Added.
         (is_integral_type, rank_one_type, recursive_dump_type): Added
         TYPE_CODE_FLAGS handling.
         (build_gdbtypes): Added builtin_type_i386_eflags initialization.
         * gdbtypes.h (type_code): Added TYPE_CODE_FLAGS.
         (builtin_type_i386_eflags): Added.
         * values.c (unpack_long: Added TYPE_CODE_FLAGS handling.
         * x86-64-tdep.c (x86_64_register_info_table): Changed type of
	eflags.

Any comments? Can I commit?

Michal Ludvig
-- 
* SuSE CR, s.r.o     * mludvig@suse.cz
* +420 2 9654 5373   * http://www.suse.cz

[-- Attachment #3.1.2: eflags.diff --]
[-- Type: text/plain, Size: 8136 bytes --]

Index: c-valprint.c
===================================================================
RCS file: /cvs/src/src/gdb/c-valprint.c,v
retrieving revision 1.13
diff -u -r1.13 c-valprint.c
--- c-valprint.c	5 Feb 2002 21:41:29 -0000	1.13
+++ c-valprint.c	22 Apr 2002 14:50:12 -0000
@@ -70,6 +70,7 @@
 	     int deref_ref, int recurse, enum val_prettyprint pretty)
 {
   register unsigned int i = 0;	/* Number of characters printed */
+  register int j;
   unsigned len;
   struct type *elttype;
   unsigned eltlen;
@@ -483,6 +484,30 @@
 			TYPE_TARGET_TYPE (type),
 			stream);
       fprintf_filtered (stream, " * I");
+      break;
+
+    case TYPE_CODE_FLAGS:
+      if (format)
+	{
+	  print_scalar_formatted (valaddr + embedded_offset, type, format, 0, stream);
+	  break;
+	}
+      len = TYPE_NFIELDS (type);
+      val = unpack_long (type, valaddr + embedded_offset);
+      fputs_filtered("[", stream);
+      for (j = len-1; j >= 0; j--)
+	{
+	  QUIT;
+	  if (TYPE_FIELD_BITPOS (type, j) != -1 && val & (1 << j))
+	  {
+		  if(TYPE_FIELD_NAME (type, j))
+			  fprintf_filtered (stream, " %s", TYPE_FIELD_NAME (type, j));
+		  else
+			  fprintf_filtered (stream, " #%d", j);
+				  
+	  }
+	}
+      fputs_filtered(" ]", stream);
       break;
 
     default:
Index: gdbtypes.c
===================================================================
RCS file: /cvs/src/src/gdb/gdbtypes.c,v
retrieving revision 1.43
diff -u -r1.43 gdbtypes.c
--- gdbtypes.c	20 Apr 2002 01:09:28 -0000	1.43
+++ gdbtypes.c	22 Apr 2002 14:50:13 -0000
@@ -99,6 +99,7 @@
 struct type *builtin_type_void_func_ptr;
 struct type *builtin_type_CORE_ADDR;
 struct type *builtin_type_bfd_vma;
+struct type *builtin_type_i386_eflags;
 
 int opaque_type_resolution = 1;
 int overload_debug = 0;
@@ -777,6 +778,67 @@
   return (result_type);
 }
 
+/*
+ * - The following three functions are intended to be used for BitFlags 
+ *   types (ie i386's EFLAGS register).
+ * - As a BitFlag we understand an integer where some bits may have 
+ *   a symbolic names that would be printed when the bit is set.
+ * - Printing is done in c_val_print() under a TYPE_CODE_FLAGS label.
+ * - All bits are set to be ignored (ie. not printed even when set) 
+ *   by default.
+ * - Add a symbolic name of relevant bits using add_flag_name() after 
+ *   an initialisation of your type.
+ */
+void
+add_flag_ignore (struct type *type, int bitpos)
+{
+	TYPE_FIELD_BITPOS (type, bitpos) = -1;
+}
+
+void
+add_flag_name (struct type *type, int bitpos, char *name)
+{
+	int namelen;
+	
+	gdb_assert (TYPE_CODE (type) == TYPE_CODE_FLAGS);
+	gdb_assert (bitpos < TYPE_NFIELDS (type));
+	gdb_assert (bitpos >= 0);
+	
+	namelen=strlen(name)+1;
+	TYPE_FIELD_NAME (type, bitpos) = xmalloc (namelen);
+	snprintf(TYPE_FIELD_NAME (type, bitpos), namelen, "%s", name);	
+
+	TYPE_FIELD_BITPOS (type, bitpos) = bitpos;
+}
+
+struct type *
+init_flags_type (int bitlength, char *name, struct objfile *objfile)
+{
+  register struct type *type;
+  int i;
+  
+  type = alloc_type (objfile);
+  
+  TYPE_CODE (type) = TYPE_CODE_FLAGS;
+  TYPE_LENGTH (type) = bitlength / 8 + ( bitlength % 8 ? 1 : 0 );
+  TYPE_FLAGS (type) = TYPE_FLAG_UNSIGNED;
+  TYPE_NFIELDS (type) = bitlength;
+  TYPE_FIELDS (type) = (struct field *)
+    TYPE_ALLOC (type, bitlength * sizeof (struct field));
+  memset (TYPE_FIELDS (type), 0, sizeof (struct field));
+
+  if ((name != NULL) && (objfile != NULL))
+      TYPE_NAME (type) =
+	obsavestring (name, strlen (name), &objfile->type_obstack);
+  else
+      TYPE_NAME (type) = name;
+  
+  for(i=0; i<bitlength; i++)
+	add_flag_ignore (type, i);
+
+  return (type);
+}
+
 /* Construct and return a type of the form:
 	struct NAME { ELT_TYPE ELT_NAME[N]; }
    We use these types for SIMD registers.  For example, the type of
@@ -1841,6 +1903,7 @@
   return
     ((t != NULL)
      && ((TYPE_CODE (t) == TYPE_CODE_INT)
+	 || (TYPE_CODE (t) == TYPE_CODE_FLAGS)
 	 || (TYPE_CODE (t) == TYPE_CODE_ENUM)
 	 || (TYPE_CODE (t) == TYPE_CODE_CHAR)
 	 || (TYPE_CODE (t) == TYPE_CODE_RANGE)
@@ -2372,6 +2435,7 @@
 	case TYPE_CODE_FUNC:
 	  return rank_one_type (TYPE_TARGET_TYPE (parm), arg);
 	case TYPE_CODE_INT:
+	case TYPE_CODE_FLAGS:
 	case TYPE_CODE_ENUM:
 	case TYPE_CODE_CHAR:
 	case TYPE_CODE_RANGE:
@@ -2448,6 +2512,8 @@
 	    return INTEGER_PROMOTION_BADNESS;
 	  else
 	    return INTEGER_COERCION_BADNESS;
+        case TYPE_CODE_FLAGS:
+	  return 0;
 	case TYPE_CODE_ENUM:
 	case TYPE_CODE_CHAR:
 	case TYPE_CODE_RANGE:
@@ -2898,6 +2964,9 @@
     case TYPE_CODE_INT:
       printf_filtered ("(TYPE_CODE_INT)");
       break;
+    case TYPE_CODE_FLAGS:
+      printf_filtered ("(TYPE_CODE_FLAGS)");
+      break;
     case TYPE_CODE_FLT:
       printf_filtered ("(TYPE_CODE_FLT)");
       break;
@@ -3318,6 +3387,28 @@
     init_type (TYPE_CODE_INT, TARGET_BFD_VMA_BIT / 8,
 	       TYPE_FLAG_UNSIGNED,
 	       "__bfd_vma", (struct objfile *) NULL);
+  builtin_type_i386_eflags = 
+    init_flags_type (32 /* EFLAGS_LENGTH */, 
+    	       "__i386_eflags", (struct objfile *) NULL);
+  add_flag_name (builtin_type_i386_eflags, 0, "CF");
+  add_flag_ignore (builtin_type_i386_eflags, 1);
+  add_flag_name (builtin_type_i386_eflags, 2, "PF");
+  add_flag_name (builtin_type_i386_eflags, 4, "AF");
+  add_flag_name (builtin_type_i386_eflags, 6, "ZF");
+  add_flag_name (builtin_type_i386_eflags, 7, "SF");
+  add_flag_name (builtin_type_i386_eflags, 8, "TF");
+  add_flag_name (builtin_type_i386_eflags, 9, "IF");
+  add_flag_name (builtin_type_i386_eflags, 10, "DF");
+  add_flag_name (builtin_type_i386_eflags, 11, "OF");
+  add_flag_ignore (builtin_type_i386_eflags, 12);
+  add_flag_ignore (builtin_type_i386_eflags, 13);
+  add_flag_name (builtin_type_i386_eflags, 14, "NT");
+  add_flag_name (builtin_type_i386_eflags, 16, "RF");
+  add_flag_name (builtin_type_i386_eflags, 17, "VM");
+  add_flag_name (builtin_type_i386_eflags, 18, "AC");
+  add_flag_name (builtin_type_i386_eflags, 19, "VIF");
+  add_flag_name (builtin_type_i386_eflags, 20, "VIP");
+  add_flag_name (builtin_type_i386_eflags, 21, "ID");
 }
 
 
Index: gdbtypes.h
===================================================================
RCS file: /cvs/src/src/gdb/gdbtypes.h,v
retrieving revision 1.27
diff -u -r1.27 gdbtypes.h
--- gdbtypes.h	23 Mar 2002 01:24:54 -0000	1.27
+++ gdbtypes.h	22 Apr 2002 14:50:13 -0000
@@ -85,6 +85,7 @@
     TYPE_CODE_ENUM,		/* Enumeration type */
     TYPE_CODE_FUNC,		/* Function type */
     TYPE_CODE_INT,		/* Integer type */
+    TYPE_CODE_FLAGS,		/* BitFlags type */
 
     /* Floating type.  This is *NOT* a complex type.  Beware, there are parts
        of GDB which bogusly assume that TYPE_CODE_FLT can mean complex.  */
@@ -930,6 +931,10 @@
 
 /* The target CPU's address type.  This is the ISA address size. */
 extern struct type *builtin_type_CORE_ADDR;
+
+/* Type for i386 EFLAGS register.  */
+extern struct type *builtin_type_i386_eflags;
+
 /* The symbol table address type.  Some object file formats have a 32
    bit address type even though the TARGET has a 64 bit pointer type
    (cf MIPS). */
Index: values.c
===================================================================
RCS file: /cvs/src/src/gdb/values.c,v
retrieving revision 1.34
diff -u -r1.34 values.c
--- values.c	29 Jan 2002 03:08:26 -0000	1.34
+++ values.c	22 Apr 2002 14:50:14 -0000
@@ -697,6 +697,7 @@
     case TYPE_CODE_ENUM:
     case TYPE_CODE_BOOL:
     case TYPE_CODE_INT:
+    case TYPE_CODE_FLAGS:
     case TYPE_CODE_CHAR:
     case TYPE_CODE_RANGE:
       if (nosign)
Index: x86-64-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/x86-64-tdep.c,v
retrieving revision 1.13
diff -u -r1.13 x86-64-tdep.c
--- x86-64-tdep.c	6 Apr 2002 00:02:50 -0000	1.13
+++ x86-64-tdep.c	22 Apr 2002 14:50:22 -0000
@@ -66,7 +66,7 @@
   {8, "r14", &builtin_type_int64},
   {8, "r15", &builtin_type_int64},
   {8, "rip", &builtin_type_void_func_ptr},
-  {4, "eflags", &builtin_type_int32},
+  {4, "eflags", &builtin_type_i386_eflags},
   {4, "ds", &builtin_type_int32},
   {4, "es", &builtin_type_int32},
   {4, "fs", &builtin_type_int32},

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

[Michal Ludvig]

[-- Attachment #1: Type: text/plain, Size: 1482 bytes --]

(Once again, now with Changelog :-)

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?)

2002-04-22  Michal Ludvig  <mludvig@suse.cz>

         * c-valprint.c (c_val_print): Added handling of TYPE_CODE_FLAGS.
         * gdbtypes.c (builtin_type_i386_eflags): Added.
         (add_flag_ignore, add_flag_name, init_flags_type): Added.
         (is_integral_type, rank_one_type, recursive_dump_type): Added
         TYPE_CODE_FLAGS handling.
         (build_gdbtypes): Added builtin_type_i386_eflags initialization.
         * gdbtypes.h (type_code): Added TYPE_CODE_FLAGS.
         (builtin_type_i386_eflags): Added.
         * values.c (unpack_long: Added TYPE_CODE_FLAGS handling.
         * x86-64-tdep.c (x86_64_register_info_table): Changed type of
	eflags.

Any comments? Can I commit?

Michal Ludvig
-- 
* SuSE CR, s.r.o     * mludvig@suse.cz
* +420 2 9654 5373   * http://www.suse.cz

[-- Attachment #2: eflags.diff --]
[-- Type: text/plain, Size: 8136 bytes --]

Index: c-valprint.c
===================================================================
RCS file: /cvs/src/src/gdb/c-valprint.c,v
retrieving revision 1.13
diff -u -r1.13 c-valprint.c
--- c-valprint.c	5 Feb 2002 21:41:29 -0000	1.13
+++ c-valprint.c	22 Apr 2002 14:50:12 -0000
@@ -70,6 +70,7 @@
 	     int deref_ref, int recurse, enum val_prettyprint pretty)
 {
   register unsigned int i = 0;	/* Number of characters printed */
+  register int j;
   unsigned len;
   struct type *elttype;
   unsigned eltlen;
@@ -483,6 +484,30 @@
 			TYPE_TARGET_TYPE (type),
 			stream);
       fprintf_filtered (stream, " * I");
+      break;
+
+    case TYPE_CODE_FLAGS:
+      if (format)
+	{
+	  print_scalar_formatted (valaddr + embedded_offset, type, format, 0, stream);
+	  break;
+	}
+      len = TYPE_NFIELDS (type);
+      val = unpack_long (type, valaddr + embedded_offset);
+      fputs_filtered("[", stream);
+      for (j = len-1; j >= 0; j--)
+	{
+	  QUIT;
+	  if (TYPE_FIELD_BITPOS (type, j) != -1 && val & (1 << j))
+	  {
+		  if(TYPE_FIELD_NAME (type, j))
+			  fprintf_filtered (stream, " %s", TYPE_FIELD_NAME (type, j));
+		  else
+			  fprintf_filtered (stream, " #%d", j);
+				  
+	  }
+	}
+      fputs_filtered(" ]", stream);
       break;
 
     default:
Index: gdbtypes.c
===================================================================
RCS file: /cvs/src/src/gdb/gdbtypes.c,v
retrieving revision 1.43
diff -u -r1.43 gdbtypes.c
--- gdbtypes.c	20 Apr 2002 01:09:28 -0000	1.43
+++ gdbtypes.c	22 Apr 2002 14:50:13 -0000
@@ -99,6 +99,7 @@
 struct type *builtin_type_void_func_ptr;
 struct type *builtin_type_CORE_ADDR;
 struct type *builtin_type_bfd_vma;
+struct type *builtin_type_i386_eflags;
 
 int opaque_type_resolution = 1;
 int overload_debug = 0;
@@ -777,6 +778,67 @@
   return (result_type);
 }
 
+/*
+ * - The following three functions are intended to be used for BitFlags 
+ *   types (ie i386's EFLAGS register).
+ * - As a BitFlag we understand an integer where some bits may have 
+ *   a symbolic names that would be printed when the bit is set.
+ * - Printing is done in c_val_print() under a TYPE_CODE_FLAGS label.
+ * - All bits are set to be ignored (ie. not printed even when set) 
+ *   by default.
+ * - Add a symbolic name of relevant bits using add_flag_name() after 
+ *   an initialisation of your type.
+ */
+void
+add_flag_ignore (struct type *type, int bitpos)
+{
+	TYPE_FIELD_BITPOS (type, bitpos) = -1;
+}
+
+void
+add_flag_name (struct type *type, int bitpos, char *name)
+{
+	int namelen;
+	
+	gdb_assert (TYPE_CODE (type) == TYPE_CODE_FLAGS);
+	gdb_assert (bitpos < TYPE_NFIELDS (type));
+	gdb_assert (bitpos >= 0);
+	
+	namelen=strlen(name)+1;
+	TYPE_FIELD_NAME (type, bitpos) = xmalloc (namelen);
+	snprintf(TYPE_FIELD_NAME (type, bitpos), namelen, "%s", name);	
+
+	TYPE_FIELD_BITPOS (type, bitpos) = bitpos;
+}
+
+struct type *
+init_flags_type (int bitlength, char *name, struct objfile *objfile)
+{
+  register struct type *type;
+  int i;
+  
+  type = alloc_type (objfile);
+  
+  TYPE_CODE (type) = TYPE_CODE_FLAGS;
+  TYPE_LENGTH (type) = bitlength / 8 + ( bitlength % 8 ? 1 : 0 );
+  TYPE_FLAGS (type) = TYPE_FLAG_UNSIGNED;
+  TYPE_NFIELDS (type) = bitlength;
+  TYPE_FIELDS (type) = (struct field *)
+    TYPE_ALLOC (type, bitlength * sizeof (struct field));
+  memset (TYPE_FIELDS (type), 0, sizeof (struct field));
+
+  if ((name != NULL) && (objfile != NULL))
+      TYPE_NAME (type) =
+	obsavestring (name, strlen (name), &objfile->type_obstack);
+  else
+      TYPE_NAME (type) = name;
+  
+  for(i=0; i<bitlength; i++)
+	add_flag_ignore (type, i);
+
+  return (type);
+}
+
 /* Construct and return a type of the form:
 	struct NAME { ELT_TYPE ELT_NAME[N]; }
    We use these types for SIMD registers.  For example, the type of
@@ -1841,6 +1903,7 @@
   return
     ((t != NULL)
      && ((TYPE_CODE (t) == TYPE_CODE_INT)
+	 || (TYPE_CODE (t) == TYPE_CODE_FLAGS)
 	 || (TYPE_CODE (t) == TYPE_CODE_ENUM)
 	 || (TYPE_CODE (t) == TYPE_CODE_CHAR)
 	 || (TYPE_CODE (t) == TYPE_CODE_RANGE)
@@ -2372,6 +2435,7 @@
 	case TYPE_CODE_FUNC:
 	  return rank_one_type (TYPE_TARGET_TYPE (parm), arg);
 	case TYPE_CODE_INT:
+	case TYPE_CODE_FLAGS:
 	case TYPE_CODE_ENUM:
 	case TYPE_CODE_CHAR:
 	case TYPE_CODE_RANGE:
@@ -2448,6 +2512,8 @@
 	    return INTEGER_PROMOTION_BADNESS;
 	  else
 	    return INTEGER_COERCION_BADNESS;
+        case TYPE_CODE_FLAGS:
+	  return 0;
 	case TYPE_CODE_ENUM:
 	case TYPE_CODE_CHAR:
 	case TYPE_CODE_RANGE:
@@ -2898,6 +2964,9 @@
     case TYPE_CODE_INT:
       printf_filtered ("(TYPE_CODE_INT)");
       break;
+    case TYPE_CODE_FLAGS:
+      printf_filtered ("(TYPE_CODE_FLAGS)");
+      break;
     case TYPE_CODE_FLT:
       printf_filtered ("(TYPE_CODE_FLT)");
       break;
@@ -3318,6 +3387,28 @@
     init_type (TYPE_CODE_INT, TARGET_BFD_VMA_BIT / 8,
 	       TYPE_FLAG_UNSIGNED,
 	       "__bfd_vma", (struct objfile *) NULL);
+  builtin_type_i386_eflags = 
+    init_flags_type (32 /* EFLAGS_LENGTH */, 
+    	       "__i386_eflags", (struct objfile *) NULL);
+  add_flag_name (builtin_type_i386_eflags, 0, "CF");
+  add_flag_ignore (builtin_type_i386_eflags, 1);
+  add_flag_name (builtin_type_i386_eflags, 2, "PF");
+  add_flag_name (builtin_type_i386_eflags, 4, "AF");
+  add_flag_name (builtin_type_i386_eflags, 6, "ZF");
+  add_flag_name (builtin_type_i386_eflags, 7, "SF");
+  add_flag_name (builtin_type_i386_eflags, 8, "TF");
+  add_flag_name (builtin_type_i386_eflags, 9, "IF");
+  add_flag_name (builtin_type_i386_eflags, 10, "DF");
+  add_flag_name (builtin_type_i386_eflags, 11, "OF");
+  add_flag_ignore (builtin_type_i386_eflags, 12);
+  add_flag_ignore (builtin_type_i386_eflags, 13);
+  add_flag_name (builtin_type_i386_eflags, 14, "NT");
+  add_flag_name (builtin_type_i386_eflags, 16, "RF");
+  add_flag_name (builtin_type_i386_eflags, 17, "VM");
+  add_flag_name (builtin_type_i386_eflags, 18, "AC");
+  add_flag_name (builtin_type_i386_eflags, 19, "VIF");
+  add_flag_name (builtin_type_i386_eflags, 20, "VIP");
+  add_flag_name (builtin_type_i386_eflags, 21, "ID");
 }
 
 
Index: gdbtypes.h
===================================================================
RCS file: /cvs/src/src/gdb/gdbtypes.h,v
retrieving revision 1.27
diff -u -r1.27 gdbtypes.h
--- gdbtypes.h	23 Mar 2002 01:24:54 -0000	1.27
+++ gdbtypes.h	22 Apr 2002 14:50:13 -0000
@@ -85,6 +85,7 @@
     TYPE_CODE_ENUM,		/* Enumeration type */
     TYPE_CODE_FUNC,		/* Function type */
     TYPE_CODE_INT,		/* Integer type */
+    TYPE_CODE_FLAGS,		/* BitFlags type */
 
     /* Floating type.  This is *NOT* a complex type.  Beware, there are parts
        of GDB which bogusly assume that TYPE_CODE_FLT can mean complex.  */
@@ -930,6 +931,10 @@
 
 /* The target CPU's address type.  This is the ISA address size. */
 extern struct type *builtin_type_CORE_ADDR;
+
+/* Type for i386 EFLAGS register.  */
+extern struct type *builtin_type_i386_eflags;
+
 /* The symbol table address type.  Some object file formats have a 32
    bit address type even though the TARGET has a 64 bit pointer type
    (cf MIPS). */
Index: values.c
===================================================================
RCS file: /cvs/src/src/gdb/values.c,v
retrieving revision 1.34
diff -u -r1.34 values.c
--- values.c	29 Jan 2002 03:08:26 -0000	1.34
+++ values.c	22 Apr 2002 14:50:14 -0000
@@ -697,6 +697,7 @@
     case TYPE_CODE_ENUM:
     case TYPE_CODE_BOOL:
     case TYPE_CODE_INT:
+    case TYPE_CODE_FLAGS:
     case TYPE_CODE_CHAR:
     case TYPE_CODE_RANGE:
       if (nosign)
Index: x86-64-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/x86-64-tdep.c,v
retrieving revision 1.13
diff -u -r1.13 x86-64-tdep.c
--- x86-64-tdep.c	6 Apr 2002 00:02:50 -0000	1.13
+++ x86-64-tdep.c	22 Apr 2002 14:50:22 -0000
@@ -66,7 +66,7 @@
   {8, "r14", &builtin_type_int64},
   {8, "r15", &builtin_type_int64},
   {8, "rip", &builtin_type_void_func_ptr},
-  {4, "eflags", &builtin_type_int32},
+  {4, "eflags", &builtin_type_i386_eflags},
   {4, "ds", &builtin_type_int32},
   {4, "es", &builtin_type_int32},
   {4, "fs", &builtin_type_int32},