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: gdb-patches@sources.redhat.com
Subject: Re: [RFA] New bitflags type and eflags on i386/x86-64
Date: Tue, 23 Apr 2002 07:32:00 -0000	[thread overview]
Message-ID: <20020423103227.A6914@nevyn.them.org> (raw)
In-Reply-To: <3CC55FF9.3030008@suse.cz>

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


  reply	other threads:[~2002-04-23 14:32 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
2002-04-29  9:54   ` Pierre Muller
2002-04-29 10:11     ` Michal Ludvig
2002-04-29 10:17     ` Daniel Jacobowitz
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
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

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=20020423103227.A6914@nevyn.them.org \
    --to=drow@mvista.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