From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 76802 invoked by alias); 8 May 2019 16:14:48 -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 76685 invoked by uid 89); 8 May 2019 16:14:48 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-10.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=HX-Languages-Length:750 X-HELO: rock.gnat.com Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 08 May 2019 16:14:47 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id BD5A211786B; Wed, 8 May 2019 12:14:45 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id t7csyysR3g6H; Wed, 8 May 2019 12:14:45 -0400 (EDT) Received: from murgatroyd (97-122-168-123.hlrn.qwest.net [97.122.168.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by rock.gnat.com (Postfix) with ESMTPSA id 57C60117865; Wed, 8 May 2019 12:14:45 -0400 (EDT) From: Tom Tromey To: Tom Tromey Cc: gdb-patches@sourceware.org Subject: Re: [PATCH 0/2] two ptype/o changes References: <20190429183105.15973-1-tromey@adacore.com> Date: Wed, 08 May 2019 16:14:00 -0000 In-Reply-To: <20190429183105.15973-1-tromey@adacore.com> (Tom Tromey's message of "Mon, 29 Apr 2019 12:31:03 -0600") Message-ID: <87sgtoly8b.fsf@tromey.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2019-05/txt/msg00197.txt.bz2 >>>>> "Tom" == Tom Tromey writes: Tom> This series changes ptype/o in a couple of ways. Tom> Last week I spent quite some time puzzling over the meaning of the Tom> 'offset' for a bitfield in ptype/o output. After talking with Sergio Tom> on irc, I ended up concluding that gdb should instead print the bit Tom> offset, not the number of bits remaining in the field's allocation. Tom> That is patch #2. Then, I noticed that the tests did not fail, Tom> despite the output changing. It turns out the tests weren't working Tom> correctly, so I wrote patch #1. Tom> Tested on x86-64 Fedora 29. Let me know what you think. Tom> Patch #2 includes a doc change. I'm checking this in now. Tom