From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 56467 invoked by alias); 12 Dec 2017 01:32:06 -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 56457 invoked by uid 89); 12 Dec 2017 01:32:05 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=xxx X-HELO: smtp.polymtl.ca Received: from smtp.polymtl.ca (HELO smtp.polymtl.ca) (132.207.4.11) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 12 Dec 2017 01:32:04 +0000 Received: from simark.ca (simark.ca [158.69.221.121]) (authenticated bits=0) by smtp.polymtl.ca (8.14.7/8.14.7) with ESMTP id vBC1VwIs006323 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 11 Dec 2017 20:32:02 -0500 Received: by simark.ca (Postfix, from userid 112) id 39F291E59D; Mon, 11 Dec 2017 20:23:55 -0500 (EST) Received: from simark.ca (localhost [127.0.0.1]) by simark.ca (Postfix) with ESMTP id 02BD81E4C4; Mon, 11 Dec 2017 20:23:53 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 12 Dec 2017 01:32:00 -0000 From: Simon Marchi To: Sergio Durigan Junior Cc: Simon Marchi , GDB Patches , Tom Tromey , Eli Zaretskii Subject: Re: [PATCH v3 2/2] Implement pahole-like 'ptype /o' option In-Reply-To: <87lgi8c0g6.fsf@redhat.com> References: <20171121160709.23248-1-sergiodj@redhat.com> <20171211195757.18044-1-sergiodj@redhat.com> <20171211195757.18044-3-sergiodj@redhat.com> <2b1ed21e-2d41-19d2-a0cf-3b4780cf9060@ericsson.com> <87lgi8c0g6.fsf@redhat.com> Message-ID: X-Sender: simon.marchi@polymtl.ca User-Agent: Roundcube Webmail/1.3.2 X-Poly-FromMTA: (simark.ca [158.69.221.121]) at Tue, 12 Dec 2017 01:31:58 +0000 X-IsSubscribed: yes X-SW-Source: 2017-12/txt/msg00267.txt.bz2 On 2017-12-11 18:24, Sergio Durigan Junior wrote: >>> + >>> + The output is strongly based on pahole(1). */ >>> + >>> +static void >>> +c_print_type_struct_field_offset (struct type *type, unsigned int >>> field_idx, >>> + unsigned int *endpos, struct ui_file *stream, >>> + unsigned int offset_bitpos) >>> +{ >>> + struct type *ftype = check_typedef (TYPE_FIELD_TYPE (type, >>> field_idx)); >>> + unsigned int bitpos = TYPE_FIELD_BITPOS (type, field_idx); >>> + unsigned int fieldsize_byte = TYPE_LENGTH (ftype); >>> + unsigned int fieldsize_bit; >>> + >>> + if (*endpos > 0 && *endpos < bitpos) >> >> Why do you check for *endpos > 0? Did you see a case where *endpos is >> 0 >> and bitpos > 0? That would mean that there's a "hole" before the >> first field. >> Would we want to show it as a hole anyway? > > Yeah, this situation happens when we have a virtual method in a class. > Because of the vtable, the first field of the struct will start at > offset 8 (for 64-bit architectures), and in this case *endpos will be 0 > because we won't have updated it, leading to a confusing message about > a > 8-byte hole in the beginning of the struct: > > ... > 50 /* offset | size */ > 51 type = struct abc { > 52 public: > 53 /* XXX 8-byte hole */ > 54 /* 8 | 8 */ void *field1; > ... > > In order to suppress this first message, I check for *endpos > 0. > > I will add a comment to the code explaining this scenario. Ah ok that makes sense. Yeah, a comment would be nice. But now I'm thinking that it would be nice if GDB showed the vtable. If I say the first field at offset 8, it would probably take me some time to get why, and would maybe think it's a bug. But if we showed a fake field, such as: /* 0 | 8 */ /* vtable */ It would be immediately obvious. Simon