This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [RFA] New bitflags type and eflags on i386/x86-64
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