Re: [RFC] printing/setting flag register fields

[Doug Evans <dje@google.com>]

On Sun, Sep 20, 2009 at 11:00 AM, Daniel Jacobowitz <drow@false.org> wrote:
> Just my two cents - flag types were a workaround for GDB's lack of
> good pretty-printing facilities.  They should be just structs
> containing bitfields, with a default pretty-printer.  And/or a union
> with an accessible integer value.  Anywhere that our handling of such
> constructs isn't good enough for eflags, it's not good enough for user
> code either, and I deal with a lot of code of this nature.

I read somewhere that one advantage of TYPE_CODE_FLAGS was that one
didn't have to deal with the vagaries of ABI-struct layout.  Alas I
can't find it now.  [And I'm not sure it's really relevant as the data
recorded in the underlying type doesn't have to follow ABI rules, so
maybe I've confused it with something else.]

Should TYPE_CODE_FLAGS be nuked?  I'm happy to do that instead if
that's what folks want.  I like it, but if we made eflags a union of a
struct and an int, then "set $eflags.ZF = 0" won't work.  Are folks
happy with "set $eflags.bits.ZF = 0"?  "works for me".

> As for bitfield numbering, I think we should use the corresponding
> architecture's conventions; I don't know what the m68k complication
> is, though.

"works for me".
My higher order question, though, is should the bitfield positions be
displayed in the output of ptype (for these objects, I wouldn't do it
by default in general of course).
I like it there so that one doesn't have to look in any manual to know
ZF, for example, is in bit 1 << 6 (gdb has so much information
internally, we should try to provide more of it to the user).
But it could be done differently.  An off-the-cuff example is an
option to ptype to print field offsets for structs in general.  [I'm
assuming such a facility doesn't already exist.]  That would probably
be more useful than always printing the offsets anyway.