Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Joel Brobecker <brobecker@adacore.com>
To: gdb-patches@sourceware.org
Subject: [RFC] future gdb-gdb.py things in my pipeline...
Date: Fri, 15 Jan 2010 09:39:00 -0000	[thread overview]
Message-ID: <20100115093910.GD6667@adacore.com> (raw)

Hello,

Just wanted to throw out some ideas based on my currently limited
amount of experience writing a pretty-printer, and maybe discuss
some of them if there is interest...

   * Tom's suggestion for structs: Return a container rather than
     doing the formatting entirely in the pretty-printer.

   * My first reaction, after having written the code, is that a lot
     of fields are handled the same; We just print their value.
     I think Daniel mentioned that as well.  There should be a way
     for us to have this happen automatically, so that the pretty
     printer specific to a given type only handles the fields that
     need special processing (flags, for instance).

     I'll try to think of something generic that allows us:
       - exclude certain fields
       - print the fields we want in the order we want
       - add certain artificial fields?
       - other requirements???

    * struct type pretty-printer.  Would it make sense to print
      the type code and name even if this information is in main_type.
      The amount of output generated is still going to be reasonable,
      while the extra data could be potentially very useful. That should
      address on of Daniel's comments, BTW.

    * Should we continue printing the contents of the "fields" array?
      For large TYPE_CODE_STRUCT types, this can generate a lot of
      output.  I was thinking maybe just print the field's address,
      and let the user print each field individually.  But this pretty
      printing is partly useful because getting to the fields is a bit
      of a pain:

          (gdb) print type.main_type.fld_bdns.fields[0]

      Right now, the fields are printed like this:

        field[1]:
          {name = 0x7f34d0c4c9aa "C6b",
           type = 0x16fd490,
           loc_kind = FIELD_LOC_KIND_BITPOS,
           bitsize = 0,
           bitpos = 128},
      
       Perhaps we could print that information in a more compact way.

         field[1]:
           {name = 0x7f34d0c4c9aa "C6b",
            type = 0x16fd490,
            loc_kind = FIELD_LOC_KIND_BITPOS, bitsize = 0, bitpos = 128}

       We could perhaps even get rid of "loc_kind", which is only useful
       to know which field to look at in the field_location union. Since
       the pretty-printer only prints the relevant field, it's a bit
       redundant.  So, we could have:

         field[1] (bisize = 0, bitpos = 128):
           {name = 0x7f34d0c4c9aa "C6b",
            type = 0x16fd490}

    * We need pretty-printers for other GDB types as well. For instance,
      a pretty-printer for struct value would be nice... Another for
      struct cplus_specific would also be useful, I think.

Voila voila...

-- 
Joel


             reply	other threads:[~2010-01-15  9:39 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-15  9:39 Joel Brobecker [this message]
2010-01-15 18:13 ` Tom Tromey

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=20100115093910.GD6667@adacore.com \
    --to=brobecker@adacore.com \
    --cc=gdb-patches@sourceware.org \
    /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