[RFC] future gdb-gdb.py things in my pipeline...

[RFC] future gdb-gdb.py things in my pipeline...

[Joel Brobecker]

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

Re: [RFC] future gdb-gdb.py things in my pipeline...

[Tom Tromey]

>>>>> "Joel" == Joel Brobecker <brobecker@adacore.com> writes:

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

If you change the printer to return a container, this problem is a lot
simpler.  For any field where you just want to see the value as gdb
would ordinarily print it, you simply append the field's value:

    result.append ('fieldname', value['fieldname'])

This is simple enough that, IMO, we don't need any extra machinery:

* To exclude a field, just don't append it.
* To order the fields, append them in the order you want.
* To add an artificial field, just append it with whatever name and
  value you want.

Joel>     * struct type pretty-printer.  Would it make sense to print
Joel>       the type code and name even if this information is in main_type.
Joel>       The amount of output generated is still going to be reasonable,
Joel>       while the extra data could be potentially very useful.

Yes please, usually when I print a struct type I want to see the name.

Joel>     * We need pretty-printers for other GDB types as well. For instance,
Joel>       a pretty-printer for struct value would be nice... 

Yeah, that would be handy.

Tom