Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Jim Blandy <jimb@codesourcery.com>
To: "Doug Evans" <dje@google.com>
Cc: gdb@sourceware.org
Subject: Re: use of python to pretty-print STL structures, etc.
Date: Sat, 22 Dec 2007 07:17:00 -0000	[thread overview]
Message-ID: <m3lk7nryf7.fsf@codesourcery.com> (raw)
In-Reply-To: <e394668d0712211357v2f097e98w4d2b09f6b75ca8fa@mail.gmail.com> (Doug Evans's message of "Fri, 21 Dec 2007 13:57:19 -0800")


"Doug Evans" <dje at google.com> writes:
> I realize there's no real design as of yet (at least that I'm aware
> of), but my question is whether folks have thought about what it would
> look like from the command line.
>
> At a very basic level, do folks envision keeping the current cli u/i
> (*1) and enhancing it to provide python-providable extensions?  Have
> folks thought about how they would like the above problem to be solved
> (with python or without)?

My dream is to let people put a gdb-custom.py file in their source
trees, and then have GDB automatically look for that and load it if
present.  gdb-custom.py would say something like:

  def print_foo (obj):
      ... code to print a GDB value whose type is 'foo' nicely ...

  print_type_with ('foo', print_foo)

And then the fundamental GDB printing code would defer to print_foo as
needed --- whether the 'foo' appeared as the entire value of the
expression, or as a member of a structure or array.  So not only
'print' and 'display', but also 'frame', 'finish', and everything else
would use print_foo.

Since gdb-custom.py would get loaded automatically, it wouldn't take
any special effort to get GDB to print a program's values in a
meaningful way --- you'd just debug the program normally, and you'd
get appropriate representations.  People who never wanted custom
printing could put 'set python auto-load off' in their ~/.gdbinit
files.

Some format specifier, say /q, would disable all custom printing
things, so you could see what was underneath it.

The output from 'print_foo' might be wrapped in some brackets or have
a special (brief) prefix to distinguish it from ordinary GDB values.

I don't know how you'd register a handler for 'vector<T>' for all T.
Or how the printing procedure would obtain the T at hand.

Maybe you'd pass an instance of some class to print_type_with, not
just a procedure, to register a collection of operations for 'foo' all
at once, if there's something we care about beyond printing.

A winning solution would have many useful, tempting examples less than
20 lines long, so people could just get the gist of the interface and
play with it.


      parent reply	other threads:[~2007-12-22  7:17 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-12-21 21:57 Doug Evans
2007-12-21 22:45 ` Vladimir Prus
2007-12-22  7:17 ` Jim Blandy [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=m3lk7nryf7.fsf@codesourcery.com \
    --to=jimb@codesourcery.com \
    --cc=dje@google.com \
    --cc=gdb@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