From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 57620 invoked by alias); 23 Jun 2018 23:44:51 -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 57610 invoked by uid 89); 23 Jun 2018 23:44:51 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.1 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=demands, opinion, 237A, consume X-HELO: mx1.redhat.com Received: from mx3-rdu2.redhat.com (HELO mx1.redhat.com) (66.187.233.73) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 23 Jun 2018 23:44:49 +0000 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 37C07401C96A; Sat, 23 Jun 2018 23:44:48 +0000 (UTC) Received: from localhost (unused-10-15-17-196.yyz.redhat.com [10.15.17.196]) by smtp.corp.redhat.com (Postfix) with ESMTP id 19C8E111AF16; Sat, 23 Jun 2018 23:44:47 +0000 (UTC) From: Sergio Durigan Junior To: Tom Tromey Cc: gdb-patches@sourceware.org Subject: Re: [RFA 0/2] Support ptype/o in Rust References: <20180623202227.17259-1-tom@tromey.com> Date: Sat, 23 Jun 2018 23:44:00 -0000 In-Reply-To: <20180623202227.17259-1-tom@tromey.com> (Tom Tromey's message of "Sat, 23 Jun 2018 14:22:25 -0600") Message-ID: <87woup9ifk.fsf@redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-IsSubscribed: yes X-SW-Source: 2018-06/txt/msg00557.txt.bz2 On Saturday, June 23 2018, Tom Tromey wrote: > This adds support for ptype/o to the Rust code. > > The first patch slightly refactors the existing ptype/o code. The > utility functions are now public methods on struct print_offset_data. Thanks for the patches, Tom. > The second patch changes the Rust language code. I would self-approve > this one but it required a change outside of Rust. Perhaps this check > ought to have been a flag on the language_defn. > > I noticed that ptype/o generates somewhat funny output: > > /* offset | size */ type = union simple::Union { > /* 1 */ f1: i8, > /* 1 */ f2: u8, > > /* total size (bytes): 1 */ > } > > Here, I think it might be cleaner to put the "total size" information > on the same line as the trailing "}" (and of course not indent it), > like: > > /* offset | size */ type = union simple::Union { > /* 1 */ f1: i8, > /* 1 */ f2: u8, > /* total size 1 */ } > > If you agree I can at least file a bug or maybe implement it. Your version does look better (and IIRC, one of the early versions of the patch printed "total size" at column 0), but I think it may be a bit confusing when we're dealing with inner structures. For example: $ cat 2.c struct a { int a1; char a2; int a3; }; struct b { struct a b1; int b2; char b3; }; struct c { struct a c1; struct b c2; char c3; int c4; }; int main () { struct c foo; return 0; } We have: (gdb) ptype /o struct c /* offset | size */ type = struct c { /* 0 | 12 */ struct a { /* 0 | 4 */ int a1; /* 4 | 1 */ char a2; /* XXX 3-byte hole */ /* 8 | 4 */ int a3; /* total size (bytes): 12 */ } c1; /* 12 | 20 */ struct b { /* 12 | 12 */ struct a { /* 12 | 4 */ int a1; /* 16 | 1 */ char a2; /* XXX 3-byte hole */ /* 20 | 4 */ int a3; /* total size (bytes): 12 */ } b1; /* 24 | 4 */ int b2; /* 28 | 1 */ char b3; /* XXX 3-byte padding */ /* total size (bytes): 20 */ } c2; /* 32 | 1 */ char c3; /* XXX 3-byte hole */ /* 36 | 4 */ int c4; /* total size (bytes): 40 */ } Even though it's a bit uglier than your solution, IMO it's easier to understand and correlate the sizes with their respective structs. Compare this to: (gdb) ptype /o struct c /* offset | size */ type = struct c { /* 0 | 12 */ struct a { /* 0 | 4 */ int a1; /* 4 | 1 */ char a2; /* XXX 3-byte hole */ /* 8 | 4 */ int a3; /* total size (bytes): 12 */ } c1; /* 12 | 20 */ struct b { /* 12 | 12 */ struct a { /* 12 | 4 */ int a1; /* 16 | 1 */ char a2; /* XXX 3-byte hole */ /* 20 | 4 */ int a3; /* total size (bytes): 12 */ } b1; /* 24 | 4 */ int b2; /* 28 | 1 */ char b3; /* XXX 3-byte padding */ /* total size (bytes): 20 */ } c2; /* 32 | 1 */ char c3; /* XXX 3-byte hole */ /* 36 | 4 */ int c4; /* total size (bytes): 40 */ } Of course, it's still possible to read the output and interpret it correctly, but it demands a bit more effort, I think. Maybe a solution would be to be a bit more verbose, like: /* total size of struct a (bytes):... */ > Additionally I noticed that in C, in most cases fields are indented 4 > spaces, but with ptype/o the outermost fields are only indented 2 > spaces (relative to the "type =" text). I think this is probably > unintended as well, but I thought I'd ask... ? I don't really remember why I made this decision. I guess it had to do with the fact that using 4 whitespaces to indent would consume a lot of unnecessary space, and since ptype/o prints more information than the regular ptype, every whitespace counts. I vaguely remember having this thought, so that may be the reason, after all. Or maybe it also had something to do with increasing the readability? Anyway, TBH I don't have a strong opinion here. If you want to indent the outermost fields by 4 spaces, I won't oppose. Thanks, -- Sergio GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36 Please send encrypted e-mail if possible http://sergiodj.net/