This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]