This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFC] printing/setting flag register fields
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.