This is the mail archive of the
archer@sourceware.org
mailing list for the Archer project.
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
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