This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: use of python to pretty-print STL structures, etc.


"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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]