Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Pedro Alves <palves@redhat.com>
To: Doug Evans <dje@google.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:10:00 -0000	[thread overview]
Message-ID: <ff50e351-0c6c-4ffd-cb47-53eef410e860@redhat.com> (raw)
In-Reply-To: <187cd5cc-be8d-3a61-66cd-338ea68a72f8@redhat.com>

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?

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


  reply	other threads:[~2016-08-11 18:10 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 [this message]
2016-08-11 18:18             ` Doug Evans
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=ff50e351-0c6c-4ffd-cb47-53eef410e860@redhat.com \
    --to=palves@redhat.com \
    --cc=cole945@gmail.com \
    --cc=dje@google.com \
    --cc=gdb-patches@sourceware.org \
    /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