Explicit Linespecs Branch Created

[Keith Seitz <keiths at redhat dot com>]

Hi,

For the past few weeks, I've been working on a little project to 
implement what I've been calling "explicit linespecs." These are 
linespecs that bypass the linespec parser altogether. [Example: "break 
-function main -label foo -offset 3"]

This feature has been requested a few times, most notably as mi/13139.

A consequence of this patch series is also that all linespecs (on 
supported breakpoint types) are now converted to this explicit form. The 
addr_string is basically used for display purposes only.

Since this patchset is so large and invasive, I have checked it into the 
Archer repository for "pre-review." It's in the 
archer-keiths-explicit-linespecs branch. I would especially appreciate 
feedback on:

- Syntax of the CLI and MI breakpoint commands.

+ MI: -break-insert -c 'foo == bar' -t -e -s source.c -f function -l 
label -o offset

Currently, the explicit linespec flag (-e) must be the last option in 
the command. Everything after "-e" is restricted to explicit linespecs. 
[This restriction was enabled so that we don't have to require some 
really ugly quoting, e.g., -break-insert -e "-f main -offset 3" -c "foo 
== bar".

+ CLI: break -source source.c -function function -label label -offset 
offset -condition "foo == bar" -thread 1

The various flags may be abbreviated, "-func" or "-f" is acceptable. 
["thread" takes precedence over "task"]

When setting an explicit linespec, users may not use the keywords "if", 
"thread", or "task". If using explicit linespecs, *everything* must be 
explicitly specified.

- New error messages

  + I have introduced several new error messages. They should be 
double-checked:
    o "invalid linespec argument, \"%s\"" : This is output when the 
user attempts to use an invalid explicit linespec flag, e.g., "-foobar".
    o "missing argument for \"%s\" : This is output when the user omits 
an argument for a given explicit linespec flag.

When these syntaxes are finalized, I will commit new documentation for 
them to the branch. [As usual, it's the last task on my TODO list. If I 
would stop finding bugs, I could probably get around to this sooner than 
later.]

This patchset is not ready for prime time (certainly not until after 7.5 
branches). I'm still dreaming up test cases, finding new bugs (e.g., 
"cond" doesn't play nicely with this yet) and tweaking this and that, 
but AFAIK, it causes no regressions in the test suite.

Any feedback appreciated,

Keith