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]

Python and structured output from breakpoint_ops


Phil and I have been discussing exposing the print_* breakpoint_ops
methods to Python, and we thought we'd take the discussion public.

Here is his latest, which quotes my latest; I'll send a reply to this
note.

--- Begin Message ---
Tom Tromey <tromey@redhat.com> writes:

> The basic problem is that a "print" method on a breakpoint can be called
> in either an MI or CLI context.  Inside gdb, we use ui_out to deal with
> this, writing ui_out calls which either print text for the CLI or
> structured output for MI.


Let me say up-front I do not disagree with the idea of structured data,
just that the current APIs limit the information we can display to a
point where the return in functionality is minimal.

Take the "print_one" operation.  This is called when "info breakpoints" is
called.

To attend to the terminology for the way GDB tries to make the breakpoint
operations OO in a C world, the "always-called" function which calls the
function-pointer for the breakpoint operation, I will call "the parent".
Similarly, the function called via function pointer (our operations) I
will call "the child".

So in print_one's case, the parent does not call the child function
until it has already populated all of the fields before address.  So
there are only two fields left to fill: "address", and "what".  They
have to be a long and a string.  Example:

class MyBreakpoint (gdb.Breakpoint):

      def print_one (self, address):
        return (address,"Our Breakpoint")

The output from "info breakpoints" from the above example:

Num     Type           Disp Enb Address            What
1       breakpoint     keep y   0x0000000000400532 Our Breakpoint

So you can see "Num, Type, Disp and Enb" have been populated before our
child function is called.  In Python at the moment we do in fact return
an iterable for this function, it just so happens we limit it to a tuple
(or None).  Given that all one can return in the above context is
essential a long and a string, I'm not sure what value we can add by
letting the user return anything else? We would have to convert any list
within the tuple to a string anyway.  I'd prefer users just do this
themselves in Python.

The same goes for print_stop_action.  This tells GDB what to print (via
an enum) when the breakpoint stops.  Example:

class MyBreakpoint (gdb.Breakpoint):

    def print_stop_action (self):
        return ("Our Breakpoint, ", gdb.PRINT_SRC_AND_LOC)

When GDB stops the inferior at a breakpoint defined by
this class, GDB will print:

Our Breakpoint, foofunc (argc=1, argv=0xff) somewhere/some-file.c:10

So again we are limited to a string and a constant.  I guess we could,
if the user passed a list within a list, call ui_out_list there.  But to
me, you will only ever want this output on one line (in fact, it may be
a requirement, I am not to sure).

There seems to be more room to maneuver with print_mention, and
print_one_detail.  They are currently implemented as pure strings.  But
again, both I believe (and really, I want) to be implemented as a single
string.  print_mention is called when a breakpoint is created.  Is there
an example of what kind of structured output we could use here?

print_one_detail is an optional detail line below each entry for "info
breakpoints".  This has to be limited to a single line, to remain
constant with "info breakpoints" output.  In fact, if you look at the mi
command -break-list, it just maps to info break and captures that
output.  Maybe that conversation is what Jan was talking about when there
is an explicit mention that any field change has to be made by Vlad?

If we are talking about refactoring breakpoint_ops themselves to allow
far broader latitude in what they output (allowing print_one to output
to all of the fields for example), or adding new fields, then that is
another kettle of  fish.

What do you think?

Cheers

Phil

> We want to mirror this capability in the Python API.  There are a lot of
> possible ways to do this.  Here's one.
>
> Instead of a "print" method on a Python breakpoint object, have a
> "describe" method that returns an iterable object (e.g., usually a
> list).  The C code will iterate over all the elements in the sequence.
> If a given element is a string, it is passed to ui_out_text.  Other
> types of elements would then be available and be converted to other
> kinds of ui_out calls.  I didn't work out all the details, but e.g., a
> Python list could be converted to a ui_out_list.
>
>
> Tom


--- End Message ---

Tom

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