This is the mail archive of the mailing list for the Archer 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: Explicit Linespecs Branch Created

On 06/15/2012 11:31 AM, Tom Tromey wrote:
I started looking at it, but really I think you should either do the
final polishing (docs and ChangeLog) and submit it; or send an RFC to
the gdb@ list.  The problem with posting here is that, even if we all
agree about everything, it'll still have to go through another round of
kibitzing when you submit it, and so you might as well skip the middle

On reflection I probably should have posted this to gdb-patches as an RFC. Next time.

I don't understand why MI needs a -e option at all.

Me either! :-) I've removed that stoopidity.

You can either have the explicit bits parsed directly, by adding options
to 'opts' in mi_cmd_break_insert; or you can just add a new
-break-insert-explicit command.

I've opted to insert the options directly to -break-insert. [Other MI commands wishing to support this could easily do the same.]

Keith>  + CLI: break -source source.c -function function -label label -offset
Keith>  offset -condition "foo == bar" -thread 1
Keith>  When setting an explicit linespec, users may not use the keywords
Keith>  "if", "thread", or "task". If using explicit linespecs, *everything*
Keith>  must be explicitly specified.

I think quoting any expression here is going to be a pain, but I'm
curious to hear what others think.

What is the reason for this approach?

The "problem" is parsing the condition/thread/task (btw, task is not propagated up the create_breakpoint API -- poor ada). It isn't a problem per se, but I was attempting to avoid the "groking UI input in a backend API" style that has caused me no end of difficulties over the years (e.g., find_condition_and_thread). IMO, that is a function of the UI to parse out those bits, not the internal breakpoint creation API.

IOW, I am/was trying to avoid implementing backend gdb APIs in terms of the command line.

How does this interact with systemtap probe point specifications?

It shouldn't. Explicit linespecs are only accepted for tracepoints and breakpoints. The explicit-releated members of struct breakpoint_ops for all other breakpoint types (like probes) is not defined/supported.

How hard is it to add support for this to other linespec-using commands?

That all depends on the UI. For the CLI, the relevant bits of code could be put into a separate function trivially enough. I didn't do that this round because I was not planning to add this feature to anything more than break_command. [list_command would be a follow-on feature addition.] But I'll do that before submitting again.

For MI, it is pretty trivial to implement with its built-in getopt functionality.

Also I wonder what the best way to expose this to Python might be; for
example if one wanted to write a Python command that accepted any sort
of linespec.

This would also be pretty easy, I should think, but I'm only a python novice. I don't see why the python API couldn't either add explicit versions of commands (eeew) or accept "function=XXX, label=xxx" tuples for those commands that accept linespecs, just like MI does (or will do).

You would know better in this case.

Thank you for taking a look.


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