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: Python and structured output from breakpoint_ops


Pedro Alves <pedro@codesourcery.com> writes:

> On Friday 07 October 2011 16:39:59, Tom Tromey wrote:
>
>> Phil> So again we are limited to a string and a constant.  I guess we could,
>> Phil> if the user passed a list within a list, call ui_out_list there.  But to
>> Phil> me, you will only ever want this output on one line (in fact, it may be
>> Phil> a requirement, I am not to sure).
>> 
>> I don't think it has to be.
>> 
>> Phil> There seems to be more room to maneuver with print_mention, and
>> Phil> print_one_detail.  They are currently implemented as pure strings.  But
>> Phil> again, both I believe (and really, I want) to be implemented as a single
>> Phil> string.  print_mention is called when a breakpoint is created.  Is there
>> Phil> an example of what kind of structured output we could use here?
>> 
>> I think I was hoping that we could unify some of the print methods.  It
>> seems strange to have 4 different method to print more or less the same
>> basic information.
>
> I still think we should cleanup the breakpoint printing machinery before
> exporting it to python.  These methods were not converted to
> breakpoint_ops yet.  By only considering a single string, you're leaving
> out breakpoints with multiple locations.  And those will become even more
> important with Tom's linespec/multi-location rework.

I've no problem with this as long as we have a plan in place, when we
think it will be released, etc.  Right now (you) did an excellent
refactor internally, but what are the future plans?  When do we plan to
have them in place?  The usual tricky question ;)

I guess I am asking what you mean by clean-ups in this context?  


>> This might mean constraining the output a little bit in order to provide
>> a simpler API.  I think that would be good, but that is just my opinion;
>> however, if it turned out to be too limiting we could always extend the
>> options later.
>> 
>> Even if all the methods can't be unified it seems that at least
>> print_one and print_one_detail could be.
>> 
>> Phil> print_one_detail is an optional detail line below each entry for "info
>> Phil> breakpoints".  This has to be limited to a single line, to remain
>> Phil> constant with "info breakpoints" output.
>> 
>> It seems like it could have multiple lines, just nothing does this yet.
>
> Yeah.  Random catchpoints are likely to want it.

In a deeper context, fully implementing catchpoint creation in Python
seems quite tricky.  Many of the catchpoint APIs seem to need to know
about deep internal GDB state.  Do we want to expose those decisions
coupled with that information externally?  We made a promise with the
Python API that it will be stable.  I've not really though about this
too much yet; there might be a clean answer just around the corner.


>> Phil> In fact, if you look at the mi command -break-list, it just maps
>> Phil> to info break and captures that output.  Maybe that conversation
>> Phil> is what Jan was talking about when there is an explicit mention
>> Phil> that any field change has to be made by Vlad?
>
> The thing is that the fields that are output aren't constrained at all
> by the "address" / "what" columns you see in the CLI.  Look at all
> the "ui_out_*" calls.  It seems quite reasonable to me to be able to
> output random fields from python too, so you could implement new
> breakpoint/catchpoints in python and forward whatever necessary info
> to the frontend through MI.

Doing that from Python would be a good idea, I agree.  We could have a
field:data structure for the user to output whatever they wish, and MI
could be taught to learn, beyond the usual fields it expects, there are
"extra" fields: ignore them or print them.  I'm not sure why the
explicit field creations needs express approval from Vlad.  Are MI
clients parsing expected only fields? Order of fields?

Cheers

Phil


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