From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 74349 invoked by alias); 11 Aug 2016 18:10:15 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 74206 invoked by uid 89); 11 Aug 2016 18:10:15 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:1470 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 11 Aug 2016 18:10:14 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id E3145C0567B2; Thu, 11 Aug 2016 18:10:12 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u7BIAB12004429; Thu, 11 Aug 2016 14:10:12 -0400 Subject: Re: [PATCH 4/5]: Enhancements to "flags": i386 cleanup To: Doug Evans References: <047d7b5dbb865204bd052cf0bc2b@google.com> <2026a39c-0b53-9142-74ce-091bc73832d8@redhat.com> <7635a6d6-4059-6b23-952c-a88dbfef3b18@redhat.com> <187cd5cc-be8d-3a61-66cd-338ea68a72f8@redhat.com> Cc: gdb-patches , Wei-cheng Wang From: Pedro Alves Message-ID: Date: Thu, 11 Aug 2016 18:10:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <187cd5cc-be8d-3a61-66cd-338ea68a72f8@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-08/txt/msg00139.txt.bz2 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 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 : There are two forms of the @samp{} element; a @samp{} 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 If a register's value is a series of single-bit flags, define it with a flags type. The @samp{} element has an explicit @var{size} and contains one or more @samp{} 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