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
next prev parent 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