From: Doug Evans <dje@google.com>
To: Pedro Alves <palves@redhat.com>
Cc: gdb-patches <gdb-patches@sourceware.org>,
Wei-cheng Wang <cole945@gmail.com>
Subject: Re: [PATCH 4/5]: Enhancements to "flags": i386 cleanup
Date: Thu, 11 Aug 2016 18:18:00 -0000 [thread overview]
Message-ID: <CADPb22SEg_GtRwsJPc9jKQv7OQ73ikwUnbqRBoR8fj1DZuaWdw@mail.gmail.com> (raw)
In-Reply-To: <ff50e351-0c6c-4ffd-cb47-53eef410e860@redhat.com>
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
>
next prev parent reply other threads:[~2016-08-11 18:18 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-29 23:09 Doug Evans
2016-07-20 18:18 ` Pedro Alves
2016-07-22 19:16 ` Doug Evans
2016-08-08 15:06 ` Pedro Alves
2016-08-08 20:34 ` Doug Evans
2016-08-09 17:55 ` Pedro Alves
2016-08-11 18:10 ` Pedro Alves
2016-08-11 18:18 ` Doug Evans [this message]
2016-10-06 11:33 ` Pedro Alves
2016-10-06 13:44 ` Anton Kolesov
2016-10-06 14:44 ` Pedro Alves
2016-10-06 18:43 ` Doug Evans
2016-08-15 19:28 Doug Evans
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CADPb22SEg_GtRwsJPc9jKQv7OQ73ikwUnbqRBoR8fj1DZuaWdw@mail.gmail.com \
--to=dje@google.com \
--cc=cole945@gmail.com \
--cc=gdb-patches@sourceware.org \
--cc=palves@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox