From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id IxlQLMsmdmDCPwAAWB0awg (envelope-from ) for ; Tue, 13 Apr 2021 19:18:35 -0400 Received: by simark.ca (Postfix, from userid 112) id A93F71F104; Tue, 13 Apr 2021 19:18:35 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id E16AC1E54D for ; Tue, 13 Apr 2021 19:18:34 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 55E7F385482F; Tue, 13 Apr 2021 23:18:34 +0000 (GMT) Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2610:1c1:1:606c::19:2]) by sourceware.org (Postfix) with ESMTPS id 5EDE53857033 for ; Tue, 13 Apr 2021 23:18:32 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 5EDE53857033 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=FreeBSD.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=jhb@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [96.47.72.80]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits)) (Client CN "mx1.freebsd.org", Issuer "R3" (verified OK)) by mx2.freebsd.org (Postfix) with ESMTPS id 873067F014; Tue, 13 Apr 2021 23:18:29 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4FKhP13Bk8z3lHS; Tue, 13 Apr 2021 23:18:29 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from John-Baldwins-MacBook-Pro.local (ralph.baldwin.cx [66.234.199.215]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id 215671135; Tue, 13 Apr 2021 23:18:29 +0000 (UTC) (envelope-from jhb@FreeBSD.org) To: Lancelot SIX , gdb-patches@sourceware.org References: <20201231125324.14779-1-lsix@lancelotsix.com> <20201231125324.14779-3-lsix@lancelotsix.com> From: John Baldwin Subject: Re: [PATCH 2/2] ptype: add option to use hexadecimal notation Message-ID: <8c431340-2115-c1f8-9568-620a175b35c9@FreeBSD.org> Date: Tue, 13 Apr 2021 16:18:24 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:78.0) Gecko/20100101 Thunderbird/78.9.0 MIME-Version: 1.0 In-Reply-To: <20201231125324.14779-3-lsix@lancelotsix.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces@sourceware.org Sender: "Gdb-patches" On 12/31/20 4:53 AM, Lancelot SIX via Gdb-patches wrote: > This commit adds a flag to the ptype command in order to print the > offsets and sizes of struct members using the hexadecimal notation. The > 'x' flag ensures use of the hexadecimal notation while the 'X' flag > ensures use of the decimal notation. The default is to use decimal > notation. > > Before this patch, gdb only uses decimal notation, as pointed out in bug > cli/22640. > > Here is an example of this new behavior with hex output turned on: > > (gdb) ptype /ox struct type_print_options > /* offset | size */ type = struct type_print_options { > /* 0x00: 0 | 0x04 */ unsigned int raw : 1; > /* 0x00: 1 | 0x04 */ unsigned int print_methods : 1; > /* 0x00: 2 | 0x04 */ unsigned int print_typedefs : 1; > /* 0x00: 3 | 0x04 */ unsigned int print_offsets : 1; > /* 0x00: 4 | 0x04 */ unsigned int print_in_hex : 1; > /* XXX 3-bit hole */ > /* XXX 3-byte hole */ > /* 0x04 | 0x04 */ int print_nested_type_limit; > /* 0x08 | 0x08 */ typedef_hash_table *local_typedefs; > /* 0x10 | 0x08 */ typedef_hash_table *global_typedefs; > /* 0x18 | 0x08 */ ext_lang_type_printers *global_printers; > > /* total size (bytes): 32 */ > } > > This patch also adds the 'set print type hex' and 'show print type hex' > commands in order to set and inspect the default behavior regarding the > use of decimal or hexadecimal notation when printing struct sizes and > offsets. > > Tested using 'runtest -tool gdb ptype-offsets.exp' Thanks for working on this. In general I think this looks fine in terms of new print flags, etc. My only concern might be that a single byte worth of space might be a bit short. I frequently use ptype with some larger data structures whose sizes in hex run to 3 digits and would distort the formatting as a result. What would you think of using 6 character fields for hex values such as 0x%04x? It would mean the entire display would shift left by 4 characters and the header would have to be adjusted. Alternatively if you are really concerned about horizontal space you could perhaps only expand the offset portion to 4 hex digits? The other possible consideration is to not print leading zeroes but instead use '%6s' with hex_string() for the hex fields. -- John Baldwin