From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 112299 invoked by alias); 12 Dec 2017 15:50:16 -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 112283 invoked by uid 89); 12 Dec 2017 15:50:15 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.2 required=5.0 tests=BAYES_00,SPF_HELO_PASS,SPF_SOFTFAIL autolearn=no version=3.3.2 spammy=Hx-languages-length:990, guys X-HELO: mail.baldwin.cx Received: from bigwig.baldwin.cx (HELO mail.baldwin.cx) (96.47.65.170) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 12 Dec 2017 15:50:13 +0000 Received: from John-Baldwins-MacBook-Pro-3.local (unknown [128.57.46.190]) by mail.baldwin.cx (Postfix) with ESMTPSA id D807410A7DB; Tue, 12 Dec 2017 10:50:10 -0500 (EST) Subject: Re: [PATCH v2] Implement pahole-like 'ptype /o' option To: Simon Marchi , Pedro Alves References: <20171121160709.23248-1-sergiodj@redhat.com> <20171128212137.15655-1-sergiodj@redhat.com> <87o9n5drbn.fsf@redhat.com> <99286acb-ce9f-42f0-41c3-ef10e03171ff@ericsson.com> <87tvwxc6t9.fsf@redhat.com> <964bae42-6e60-4e9d-048c-ef570c1d3a5b@redhat.com> <87fu8gdgl8.fsf@redhat.com> <0d314798-6e0d-f7a9-ace8-3cb43bda9947@redhat.com> <87shcg94hp.fsf@redhat.com> <750e0e54f663f81c1f7bf7207bc1e814@polymtl.ca> Cc: Sergio Durigan Junior , Simon Marchi , GDB Patches , Tom Tromey , Eli Zaretskii From: John Baldwin Message-ID: Date: Tue, 12 Dec 2017 15:50:00 -0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <750e0e54f663f81c1f7bf7207bc1e814@polymtl.ca> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2017-12/txt/msg00277.txt.bz2 On 12/11/17 8:25 PM, Simon Marchi wrote: > On 2017-12-11 19:51, Pedro Alves wrote: >>>> So from that angle, I see value in not printing the offsets >>>> of union members. >>> >>> Since it's still not clear whether the offsets should be printed or >>> not >>> in this case, and I am not a global maintainer, I adjusted the code to >>> print them and will post the patch as a reply to the v4 e-mail. This >>> way you can decide which version is best. >> >> Fun, just when I agreed with not printing the offsets... :-P :-) > > Damn, sorry for starting you guys on that track! I just wanted to know > if it was intentional or not, I am fine with either. The only reason I would find the offset usable is to know the offset of a structure member inside of a union. E.g.: struct foo { int x; union { struct { int y; int z; }; int a; }; }; I think it is useful to know the offset of 'foo.z' within the overall structure. -- John Baldwin