From: Pedro Alves <pedro@codesourcery.com>
To: pmuldoon@redhat.com
Cc: gdb@sourceware.org, Tom Tromey <tromey@redhat.com>
Subject: Re: Python and structured output from breakpoint_ops
Date: Mon, 10 Oct 2011 18:47:00 -0000 [thread overview]
Message-ID: <201110101946.52154.pedro@codesourcery.com> (raw)
In-Reply-To: <m38votcib7.fsf@redhat.com>
On Monday 10 October 2011 10:22:20, Phil Muldoon wrote:
> Pedro Alves <pedro@codesourcery.com> writes:
>
> > 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?
The next step is to make breakpoint_ops->print_one work
with regular breakpoints. print_one_breakpoint /
print_one_breakpoint_location were never converted to breakpoint_ops.
This is not a case of the internal abstractions being too
detailed/internal to want to expose to python. Rather it's a case
of the internal abstraction not being good even for GDBs own internals!
If we fix this (pick print_one_breakpoint / print_one_breakpoint_location
apart in a way that the core breakpoint print code doesn't know about
specific breakpoint types), then you win a good python abstraction
as a co/by-product. IOW, or from a different angle, if you come up with
a nice python abstraction for this, there's no reason that the core
wouldn't want the same nice abstraction too. But only by cleaning up
the core can you know you _have_ a good abstraction.
> When do we plan to have them in place? The usual tricky question ;)
Ah, if days had infinite hours... :-) I don't have time presently
to work on that myself until next January.
> I guess I am asking what you mean by clean-ups in this context?
See above.
> >> 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.
Catchpoints that I'd find useful to write in python would for example
be things like putting a breakpoint in a special routine in your
special domain specific or embedded OS runtime -- "catch my-special-event".
You'd want to hide the fact that that's implemented by placing a
breakpoint, and the support is all there (I believe).
> >> 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?
I'm not really sure I understand what you're asking.
--
Pedro Alves
next prev parent reply other threads:[~2011-10-10 18:47 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-07 15:16 Tom Tromey
2011-10-07 15:40 ` Tom Tromey
2011-10-07 16:04 ` Pedro Alves
2011-10-10 9:22 ` Phil Muldoon
2011-10-10 18:47 ` Pedro Alves [this message]
2011-10-10 9:14 ` Phil Muldoon
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=201110101946.52154.pedro@codesourcery.com \
--to=pedro@codesourcery.com \
--cc=gdb@sourceware.org \
--cc=pmuldoon@redhat.com \
--cc=tromey@redhat.com \
/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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).