Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Daniel Jacobowitz <drow@false.org>
To: Joel Brobecker <brobecker@adacore.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [RFC] embryo of type/main_type pretty_printing...
Date: Tue, 22 Dec 2009 19:24:00 -0000	[thread overview]
Message-ID: <20091222192358.GA15339@caradoc.them.org> (raw)
In-Reply-To: <20091220074121.GG2804@adacore.com>

On Sun, Dec 20, 2009 at 11:41:21AM +0400, Joel Brobecker wrote:
> Hello,
> 
> As discussed with Daniel and Tom on IRC, I started looking at writing
> pretty printers for struct type and struct main_type.  I have not fully
> tested it yet, just with various integer types (not even range types).
> It's just a prototype at this stage.  But before finishing this up,
> I want to finish up the patch I have been working on on-and-off, that
> will provide a discriminant for the type-specific stuff, making it
> easier to print the right component for type_specific.

Cool!

> Eventually, I think it'd be nice if we printed the data even more
> intelligently, omitting fields that are not relevant for the given
> type_code for instance. Or perhaps, we might want to leave the
> C-like representation, and show something more synthetic, tailored
> for each type kind.

Yeah, I was thinking maybe a summary followed by a more verbose
version... just an idea.

I took a look at the patch.

It would be nice if we could simplify the amount of code you had to
write in order to make this an easily generalizable framework.  The
specific change you've made so far is to assign a special printer
to the flags and instance flags members of the structs.  If we could
do that declaratively you wouldn't have to bake in knowledge about the
whole field.  I think this is something we can do entirely in Python.

Another rule that would be nice to apply to an element would be
"automatically dereference main_type".  Can we do that?  It's always
what I'm looking for because it has the code and the name.

>     def __str__(self):
>         global TYPE_FLAGS
>         if TYPE_FLAGS is None:
>             self.init_TYPE_FLAGS()
>         if not self.val:
>             return "0"
>         if TYPE_FLAGS:
>             flag_list = [flag.short_name for flag in TYPE_FLAGS
>                          if self.val & flag.value]
>         else:
>             flag_list = ["???"]
>         return "0x%x [%s]" % (self.val, "|".join(flag_list))

A future enhancement to general flag printing would be to show unknown
bits in hex - then it's obvious something odd is going on.

>     def to_string(self):
>         fields = []
>         fields.append("pointer_type = %s" % self.val['pointer_type'])
>         fields.append("reference_type = %s" % self.val['reference_type'])
>         fields.append("chain = %s" % self.val['reference_type'])
>         fields.append("instance_flags = %s"
>                       % TypeFlagsPrinter(self.val['instance_flags']))
>         fields.append("length = %d" % self.val['length'])
>         fields.append("main_type = %s" % self.val['main_type'])
>         return "\n{" + ",\n ".join(fields) + "}"

Typo on printing chain.  It'd be nice if we could examine the type to
get the field list.

>         # We need to locate the objfile corresponding to the GDB
>         # executable, and register the pretty-printer for that objfile.
>         # FIXME: The condition used to match the objfile is too simplistic
>         # and will not work on Windows.
>         for objfile in gdb.objfiles():
>             if os.path.basename(objfile.filename) == "gdb":
>                 objfile.pretty_printers.append(type_lookup_function)

Want to key off a function?  gdb_main, perhaps.

Like Tom, I think this can go straight in even as a work-in-progress.
It's for developers, and it's better than not.

-- 
Daniel Jacobowitz
CodeSourcery


      parent reply	other threads:[~2009-12-22 19:24 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-12-20  7:41 Joel Brobecker
2009-12-22 18:42 ` Tom Tromey
2009-12-23  7:08   ` Joel Brobecker
2010-01-05 23:12     ` Tom Tromey
2010-01-06  3:51       ` Joel Brobecker
2009-12-22 19:24 ` Daniel Jacobowitz [this message]

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=20091222192358.GA15339@caradoc.them.org \
    --to=drow@false.org \
    --cc=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