Re: Explicit Linespecs Branch Created

[Keith Seitz <keiths@redhat.com>]

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
> man.

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.

Keith