This is the mail archive of the 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 wrote:

> Hi.  Python scripting support will eventually be added to gdb.  I'd
> like to better understand folks's views on if/how Python will help
> with one sore spot in gdb, namely the printing of c++ data structures
> in a way that is useful to the programmer, instead of the raw dump
> that is done today.
> e.g. instead of
> #include <string>
> string s ("hello");
> int main () { return 0; }
> (gdb) p s
> $1 = {static npos = 4294967295,
>   _M_dataplus = {<std::allocator<char>> =
> {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data
> fields>}, _M_p = 0x9783014 "hello"}}
> and staring at the output to find what one wants, or doing "p
> s._M_dataplus._M_p", programmers would often rather just do something
> like "p s" and get "hello".  Similarily for vectors, etc.
> As I understand it, and I'm sure you'll correct me if I'm wrong :-),
> the plan is to solve this problem with the new Python scripting
> support.
> 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)?
> ---
> (*1): One can replace the implementation as desired, it's the u/i I'm
> concerned with in this message.

As you mention, no real design exists yet. What I personally plan to try
is to implement MI support -- where one can have "smart" variable objects,
such that the list of children is computed by Python code.

For my purposes, it would be sufficient if GUI could say "use this Python"
code to compute children of this variable object (or type)".

For strings, we'd probably need to customize how a varobj is actually
converted to text, as opposed to customizing getting children, but
customizing conversion to text is easier.

Anyway, the biggest part of this project appears to be exposing all the
necessary functionality to python -- the value machinery, first of all.

- Volodya

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