This is the mail archive of the gdb-patches@sourceware.org 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: [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.


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