This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH 4/5]: Enhancements to "flags": i386 cleanup
On Thu, Aug 11, 2016 at 11:10 AM, Pedro Alves <palves@redhat.com> wrote:
> On 08/09/2016 06:55 PM, Pedro Alves wrote:
>
>> Thanks! All looks good to me.
>
> A thought has been running through my mind though.
>
> Is the "type" attribute used for anything in <flags> elements?
> Does changing the type of a flag bitfield have any user-visible
> effect at all? I.e., does a 1-bit uint32_t bitfield flag
> print differently from a bool bitfield flag?
There may be some simplification possible, but note that bools do
print differently: if false we don't print the field at all.
[digression: I'm not sure it's possible today, but while I understand
the desire to avoid the extra verbosity if we always printed false
fields, there are times when I *do* want the field printed even if
false]
>
> Wondering if we could remove the bool-special case, because
> before 8151645076ce927e0ee866c598a19f192e68e103, we used to say,
> for <struct>:
>
> There are two forms of the @samp{<struct>}
> element; a @samp{<struct>} element must either contain only bitfields
> or contain no bitfields. If the structure contains only bitfields,
> its total size in bytes must be specified, each bitfield must have an
> explicit start and end, and bitfields are automatically assigned an
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> integer type. The field's @var{start} should be less than or
> ^^^^^^^^^^^^
> equal to its @var{end}, and zero represents the least significant bit.
>
> And for flags, we used to say:
>
> @cindex <flags>
> If a register's value is a series of single-bit flags, define it with
> a flags type. The @samp{<flags>} element has an explicit @var{size}
> and contains one or more @samp{<field>} elements. Each field has a
> @var{name}, a @var{start}, and an @var{end}. Only single-bit flags
> are supported.
>
> I think I may be very confused by this all, though.
>
> Thanks,
> Pedro Alves
>