Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Pedro Alves <palves@redhat.com>
To: Sergio Durigan Junior <sergiodj@redhat.com>,
	GDB Patches <gdb-patches@sourceware.org>
Cc: Tom Tromey <tom@tromey.com>, Eli Zaretskii <eliz@gnu.org>,
	Simon Marchi <simon.marchi@ericsson.com>,
	Keith Seitz <keiths@redhat.com>
Subject: Re: [PATCH v5 2/2] Implement pahole-like 'ptype /o' option
Date: Wed, 13 Dec 2017 16:20:00 -0000	[thread overview]
Message-ID: <2c84dc10-a131-31bb-8db5-74c3b3d3a95e@redhat.com> (raw)
In-Reply-To: <20171213031724.22721-3-sergiodj@redhat.com>

[Sending user-interface suggestions separately from core
functionality review.]

On 12/13/2017 03:17 AM, Sergio Durigan Junior wrote:
>   (gdb) ptype /o stap_probe
>   /* offset    |  size */
>   struct stap_probe {
>   /*    0      |    40 */    struct probe {
>   /*    0      |     8 */        const probe_ops *pops;
>   /*    8      |     8 */        gdbarch *arch;
>   /*   16      |     8 */        const char *name;
>   /*   24      |     8 */        const char *provider;
>   /*   32      |     8 */        CORE_ADDR address;
> 			     } /* total size:   40 bytes */ p;
>   /*   40      |     8 */    CORE_ADDR sem_addr;
>   /*   48:31   |     4 */    unsigned int args_parsed : 1;
>   /* XXX  7-bit hole   */
>   /* XXX  7-byte hole  */
>   /*   56      |     8 */    union {
>   /*                 8 */        const char *text;
>   /*                 8 */        VEC_stap_probe_arg_s *vec;
> 			     } /* total size:    8 bytes */ args_u;
>   } /* total size:   64 bytes */

I've experimented with (different versions of) of this patch
against gdb a bit, and I have to say that I'm finding myself
a bit confused by the currently produced output.  It feels
like the output should be a bit more obvious and easier to
skim quickly.

For example, I was looking at gdb's minimal_symbol (what I had
used when I noticed the bitfield handling in earlier versions was
incorrect):

(top-gdb) ptype/tom minimal_symbol
/* offset    |  size */
type = struct minimal_symbol {
/*    0      |    32 */    struct general_symbol_info {
/*    0      |     8 */        const char *name;
/*    8      |     8 */        union {
/*                 8 */            LONGEST ivalue;
/*                 8 */            const block *block;
/*                 8 */            const gdb_byte *bytes;
/*                 8 */            CORE_ADDR address;
/*                 8 */            const common_block *common_block;
/*                 8 */            symbol *chain;
                               } /* total size:    8 bytes */ value;
/*   16      |     8 */        union {
/*                 8 */            obstack *obstack;
/*                 8 */            const char *demangled_name;
                               } /* total size:    8 bytes */ language_specific;
/*   24:27   |     4 */        language language : 5;
/*   24:26   |     4 */        unsigned int ada_mangled : 1;
/* XXX  2-bit hole   */
/* XXX  1-byte hole  */
/*   26      |     2 */        short section;
                           } /* total size:   32 bytes */ mginfo;
/*   32      |     8 */    unsigned long size;
/*   40      |     8 */    const char *filename;
/*   48:28   |     4 */    minimal_symbol_type type : 4;
/*   48:27   |     4 */    unsigned int created_by_gdb : 1;
/*   48:26   |     4 */    unsigned int target_flag_1 : 1;
/*   48:25   |     4 */    unsigned int target_flag_2 : 1;
/*   48:24   |     4 */    unsigned int has_size : 1;
/* XXX  7-byte hole  */
/*   56      |     8 */    minimal_symbol *hash_next;
/*   64      |     8 */    minimal_symbol *demangled_hash_next;
} /* total size:   72 bytes */
(top-gdb) 

and I have the following observations:

#1 - left vs right

We print the extra offset/size info on the leftside of the
screen, shifting the whole type to the right.  If we were to put
the new info on the right, then a "ptype S" vs "ptype/o S" would
look mostly the same, except for the extra info that appears
on the right, and it'd map better to what you'd write in
actual code (who puts comments on the left side, right?)
pahole(1) prints the info on the right side.  Was there a
particular reason gdb's version prints it on the left hand
side?  Maybe the Python version did that too (did it?  I haven't
tried it) because it'd be difficult with the Python
implementation otherwise?  

But maybe it's just me.  On to the next point in
such case.

#2 - shift "type =" header to the right as well?

Currently, the leading "type =" and ending "}" lines
are aligned on the left, along with the offset/size info.
I think shifting those to the right as well might make the
output nicer.  The idea being that /o would split the
output in two more-clearly-separated columns, with the new info
panned hard on the left column, and old ptype info on
the right column.

I.e., currently we get:

~~~~~~~~~~~~~~~~~~~~~~~~~~~
(top-gdb) ptype/o minimal_symbol
/* offset    |  size */
type = struct minimal_symbol {
/*    0      |    32 */    struct general_symbol_info {
/*    0      |     8 */        const char *name;
...
} /* total size:   72 bytes */
~~~~~~~~~~~~~~~~~~~~~~~~~~~

And I'd propose instead:

~~~~~~~~~~~~~~~~~~~~~~~~~~~
(top-gdb) ptype/o minimal_symbol
/* offset    |  size */
                         type = struct minimal_symbol {
/*    0      |    32 */    struct general_symbol_info {
/*    0      |     8 */        const char *name;
...
                         } /* total size:   72 bytes */
~~~~~~~~~~~~~~~~~~~~~~~~~~~

Or even saving one line:

~~~~~~~~~~~~~~~~~~~~~~~~~~~
(top-gdb) ptype/o minimal_symbol
/* offset    |  size */  type = struct minimal_symbol {
/*    0      |    32 */    struct general_symbol_info {
/*    0      |     8 */        const char *name;
...
                         } /* total size:   72 bytes */
~~~~~~~~~~~~~~~~~~~~~~~~~~~


Or in full (compare to the version further above):

(top-gdb) ptype/o minimal_symbol
/* offset    |  size */  type = struct minimal_symbol {
/*    0      |    32 */    struct general_symbol_info {
/*    0      |     8 */        const char *name;
/*    8      |     8 */        union {
/*                 8 */            LONGEST ivalue;
/*                 8 */            const block *block;
/*                 8 */            const gdb_byte *bytes;
/*                 8 */            CORE_ADDR address;
/*                 8 */            const common_block *common_block;
/*                 8 */            symbol *chain;
                               } /* total size:    8 bytes */ value;
/*   16      |     8 */        union {
/*                 8 */            obstack *obstack;
/*                 8 */            const char *demangled_name;
                               } /* total size:    8 bytes */ language_specific;
/*   24:27   |     4 */        language language : 5;
/*   24:26   |     4 */        unsigned int ada_mangled : 1;
/* XXX  2-bit hole   */
/* XXX  1-byte hole  */
/*   26      |     2 */        short section;
                           } /* total size:   32 bytes */ mginfo;
/*   32      |     8 */    unsigned long size;
/*   40      |     8 */    const char *filename;
/*   48:28   |     4 */    minimal_symbol_type type : 4;
/*   48:27   |     4 */    unsigned int created_by_gdb : 1;
/*   48:26   |     4 */    unsigned int target_flag_1 : 1;
/*   48:25   |     4 */    unsigned int target_flag_2 : 1;
/*   48:24   |     4 */    unsigned int has_size : 1;
/* XXX  7-byte hole  */
/*   56      |     8 */    minimal_symbol *hash_next;
/*   64      |     8 */    minimal_symbol *demangled_hash_next;
                         } /* total size:   72 bytes */
(top-gdb) 


#3 - I also find the position of those
"/* total size:    8 bytes */"  markers a bit hard
to grok/spot.

I'd suggest considering putting them on the left column
along with the rest of the offset/size info as well, like:

(top-gdb) ptype/tom minimal_symbol
/* offset    |  size */
type = struct minimal_symbol {
/*    0      |    32 */    struct general_symbol_info {
/*    0      |     8 */        const char *name;
/*    8      |     8 */        union {
/*                 8 */            LONGEST ivalue;
/*                 8 */            const block *block;
/*                 8 */            const gdb_byte *bytes;
/*                 8 */            CORE_ADDR address;
/*                 8 */            const common_block *common_block;
/*                 8 */            symbol *chain;
/* total size:     8 */        } value;
/*   16      |     8 */        union {
/*                 8 */            obstack *obstack;
/*                 8 */            const char *demangled_name;
/* total size:     8 */        } language_specific;
/*   24:27   |     4 */        language language : 5;
/*   24:26   |     4 */        unsigned int ada_mangled : 1;
/* XXX  2-bit hole   */
/* XXX  1-byte hole  */
/*   26      |     2 */        short section;
/* total size:    32 */    } mginfo;
/*   32      |     8 */    unsigned long size;
/*   40      |     8 */    const char *filename;
/*   48:28   |     4 */    minimal_symbol_type type : 4;
/*   48:27   |     4 */    unsigned int created_by_gdb : 1;
/*   48:26   |     4 */    unsigned int target_flag_1 : 1;
/*   48:25   |     4 */    unsigned int target_flag_2 : 1;
/*   48:24   |     4 */    unsigned int has_size : 1;
/* XXX  7-byte hole  */
/*   56      |     8 */    minimal_symbol *hash_next;
/*   64      |     8 */    minimal_symbol *demangled_hash_next;
} /* total size:   72 bytes */
(top-gdb) 

Or if you don't like it, consider putting that 
"total size:" info on a separate line before the struct/union
is closed, like pahole does:

        /* size: 128, cachelines: 2, members: 4 */
        /* sum members: 124, holes: 1, sum holes: 4 */
};

That may be even better because it provides a place
to put extra info, like pahole does (cacheline info etc.).

Thanks,
Pedro Alves


  parent reply	other threads:[~2017-12-13 16:20 UTC|newest]

Thread overview: 75+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-21 16:07 [PATCH] " Sergio Durigan Junior
2017-11-21 16:16 ` Sergio Durigan Junior
2017-11-21 16:50 ` Eli Zaretskii
2017-11-21 17:00   ` Sergio Durigan Junior
2017-11-21 19:14     ` Eli Zaretskii
2017-11-26 19:27 ` Tom Tromey
2017-11-27 19:54   ` Sergio Durigan Junior
2017-11-27 22:20     ` Tom Tromey
2017-11-28  0:39       ` Sergio Durigan Junior
2017-11-28 21:21 ` [PATCH v2] " Sergio Durigan Junior
2017-11-29  3:28   ` Eli Zaretskii
2017-12-04 15:03   ` Sergio Durigan Junior
2017-12-04 15:41     ` Eli Zaretskii
2017-12-04 16:47       ` Sergio Durigan Junior
2017-12-08 21:32     ` Sergio Durigan Junior
2017-12-11 15:43   ` Simon Marchi
2017-12-11 18:59     ` Sergio Durigan Junior
2017-12-11 20:45       ` Simon Marchi
2017-12-11 21:07         ` Sergio Durigan Junior
2017-12-11 22:42           ` Pedro Alves
2017-12-11 22:50             ` Sergio Durigan Junior
2017-12-11 23:46               ` Pedro Alves
2017-12-12  0:25                 ` Sergio Durigan Junior
2017-12-12  0:52                   ` Pedro Alves
2017-12-12  1:25                     ` Simon Marchi
2017-12-12 15:50                       ` John Baldwin
2017-12-12 17:04                         ` Sergio Durigan Junior
2017-12-11 19:58 ` [PATCH v3 0/2] Implement pahole-like 'ptype /o' option (and do some code reorg) Sergio Durigan Junior
2017-12-11 19:58   ` [PATCH v3 2/2] Implement pahole-like 'ptype /o' option Sergio Durigan Junior
2017-12-11 21:50     ` Simon Marchi
2017-12-11 23:24       ` Sergio Durigan Junior
2017-12-12  1:32         ` Simon Marchi
2017-12-12  6:19           ` Sergio Durigan Junior
2017-12-12 18:14             ` Pedro Alves
2017-12-12 18:40               ` Sergio Durigan Junior
2017-12-12 20:12                 ` Pedro Alves
2017-12-11 19:58   ` [PATCH v3 1/2] Reorganize code to handle TYPE_CODE_{STRUCT,UNION} on 'c_type_print_base' Sergio Durigan Junior
2017-12-11 20:55     ` Simon Marchi
2017-12-11 23:05       ` Sergio Durigan Junior
2017-12-11 23:43 ` [PATCH v4 0/2] Implement pahole-like 'ptype /o' option (and do some code reorg) Sergio Durigan Junior
2017-12-11 23:44   ` [PATCH v4 2/2] Implement pahole-like 'ptype /o' option Sergio Durigan Junior
2017-12-12  0:27     ` Sergio Durigan Junior
2017-12-12  0:29       ` Sergio Durigan Junior
2017-12-12  1:59     ` Simon Marchi
2017-12-12  3:39     ` Eli Zaretskii
2017-12-11 23:44   ` [PATCH v4 1/2] Reorganize code to handle TYPE_CODE_{STRUCT,UNION} on 'c_type_print_base' Sergio Durigan Junior
2017-12-13  3:17 ` [PATCH v5 0/2] Implement pahole-like 'ptype /o' option (and do some code reorg) Sergio Durigan Junior
2017-12-13  3:17   ` [PATCH v5 1/2] Reorganize code to handle TYPE_CODE_{STRUCT,UNION} on 'c_type_print_base' Sergio Durigan Junior
2017-12-13  3:17   ` [PATCH v5 2/2] Implement pahole-like 'ptype /o' option Sergio Durigan Junior
2017-12-13  4:50     ` Simon Marchi
2017-12-13 16:42       ` Sergio Durigan Junior
2017-12-13 16:17     ` Eli Zaretskii
2017-12-13 17:14       ` Sergio Durigan Junior
2017-12-13 16:19     ` Pedro Alves
2017-12-13 17:13       ` Sergio Durigan Junior
2017-12-13 20:36         ` Sergio Durigan Junior
2017-12-13 21:22           ` Pedro Alves
2017-12-13 21:30             ` Pedro Alves
2017-12-13 21:34             ` Sergio Durigan Junior
2017-12-13 16:20     ` Pedro Alves [this message]
2017-12-13 17:41       ` Sergio Durigan Junior
2017-12-14  2:48 ` [PATCH v6 0/2] Implement pahole-like 'ptype /o' option (and do some code reorg) Sergio Durigan Junior
2017-12-14  2:48   ` [PATCH v6 1/2] Reorganize code to handle TYPE_CODE_{STRUCT,UNION} on 'c_type_print_base' Sergio Durigan Junior
2017-12-14  2:48   ` [PATCH v6 2/2] Implement pahole-like 'ptype /o' option Sergio Durigan Junior
2017-12-14 14:19     ` Pedro Alves
2017-12-14 20:31       ` Sergio Durigan Junior
2017-12-14 14:50     ` Pedro Alves
2017-12-14 20:29       ` Sergio Durigan Junior
2017-12-14 16:30     ` Eli Zaretskii
2017-12-15  1:12 ` [PATCH v7 0/2] Implement pahole-like 'ptype /o' option (and do some code reorg) Sergio Durigan Junior
2017-12-15  1:12   ` [PATCH v7 1/2] Reorganize code to handle TYPE_CODE_{STRUCT,UNION} on 'c_type_print_base' Sergio Durigan Junior
2017-12-15  1:13   ` [PATCH v7 2/2] Implement pahole-like 'ptype /o' option Sergio Durigan Junior
2017-12-15 17:24     ` Pedro Alves
2017-12-15 20:04       ` Sergio Durigan Junior
2017-12-15 20:11   ` [PATCH v7 0/2] Implement pahole-like 'ptype /o' option (and do some code reorg) Sergio Durigan Junior

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2c84dc10-a131-31bb-8db5-74c3b3d3a95e@redhat.com \
    --to=palves@redhat.com \
    --cc=eliz@gnu.org \
    --cc=gdb-patches@sourceware.org \
    --cc=keiths@redhat.com \
    --cc=sergiodj@redhat.com \
    --cc=simon.marchi@ericsson.com \
    --cc=tom@tromey.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox