Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Daniel Jacobowitz <drow@mvista.com>
To: Michal Ludvig <mludvig@suse.cz>
Cc: Andrew Cagney <ac131313@redhat.com>, gdb-patches@sources.redhat.com
Subject: Re: [RFA] New bitflags type and eflags on i386/x86-64
Date: Thu, 29 Aug 2002 07:57:00 -0000	[thread overview]
Message-ID: <20020829142120.GA5176@nevyn.them.org> (raw)
In-Reply-To: <3D6E231D.8060906@suse.cz>

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


  reply	other threads:[~2002-08-29 14:20 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-04-22  8:35 Michal Ludvig
2002-08-27 14:50 ` Andrew Cagney
2002-08-28  7:48   ` Michal Ludvig
2002-08-28  8:08     ` Daniel Jacobowitz
2002-08-28  8:09       ` Michal Ludvig
2002-08-28 10:03       ` Andrew Cagney
2002-08-29  7:20   ` Michal Ludvig
2002-08-29  7:57     ` Daniel Jacobowitz [this message]
2002-08-29  8:03       ` Michal Ludvig
2002-08-29  8:15         ` Daniel Jacobowitz
2002-08-29  8:59           ` Andrew Cagney
2002-08-29 16:37             ` Mark Kettenis
2002-08-30  7:09               ` Michal Ludvig
2002-08-30  7:05             ` Michal Ludvig
2002-08-30  7:12               ` Pierre Muller
2002-08-30  7:41                 ` Michal Ludvig
2002-08-30  8:14                   ` Daniel Jacobowitz
2002-08-30 10:18                     ` Pierre Muller
2002-09-03  2:17                       ` Michal Ludvig
2002-09-03  5:30                         ` Daniel Jacobowitz
2002-09-05  1:04                           ` Michal Ludvig
2002-09-06 13:01                             ` Mark Kettenis
2002-09-09 20:35                               ` Andrew Cagney
  -- strict thread matches above, loose matches on Subject: below --
2002-04-22  8:15 Michal Ludvig
2002-04-22  8:45 ` Daniel Jacobowitz
2002-04-22  9:08   ` Michal Ludvig
2002-04-22 19:05     ` Andrew Cagney
2002-04-22 21:28     ` Daniel Jacobowitz
2002-04-23  6:22       ` Michal Ludvig
2002-04-23  7:32         ` Daniel Jacobowitz
2002-04-29  9:54   ` Pierre Muller
2002-04-29 10:11     ` Michal Ludvig
2002-04-29 10:17     ` Daniel Jacobowitz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20020829142120.GA5176@nevyn.them.org \
    --to=drow@mvista.com \
    --cc=ac131313@redhat.com \
    --cc=gdb-patches@sources.redhat.com \
    --cc=mludvig@suse.cz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox