Re: [RFC] canonical linespec and multiple breakpoints ...

[Tom Tromey <tromey at redhat dot com>]

Eli> Maybe a useful interim step would be reworking the description you
Eli> posted into a concise list of broad use case classes and issues that
Eli> need to be solved in each class.  We can then brainstorm possible
Eli> solutions against that list.

Here are the various scenarios in a more CLI-centric way.  I think it is
important to consider how a proposed plan handles each one.  Note that
in many cases the content of the linespec is unimportant, nearly any of
them can be made to be ambiguous; this happens in real programs.

1. Break on an ambiguously-named function.

    $ gdb gdb
    (gdb) break parse_number

  Today we pick one:

    Breakpoint 1 at 0x7e7a54: file ../../src/gdb/p-exp.y, line 856.


2. The same, but with a file:line.


3. Set a breakpoint at a SystemTap probe, the thing that started all this:

    (gdb) break probe:longjmp

   This one (in Fedora 15 glibc) happens to have 2 locations.


4. Set a pending breakpoint.

   (gdb) break lib_function

5. The same, but the pending name is ambiguous.

6. Set a breakpoint that has a match in the inferior.  Then the inferior
   loads a .so to make the linespec ambiguous.

7. 'break main', then start multiple inferiors

8. Any of the above, but with a breakpoint condition.
   Of particular importance is the case where the condition cannot be
   parsed in one location.

9. An ambiguous linespec where one match has debuginfo and another does
   not.


I left off the MI and Python stuff.  I don't think those will have a
significant impact on the choices; the question is really how we want
the user to interact with GDB.

I will post my proposal and rundown of the scenarios separately.

Tom