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

Tom Tromey
2011-06-30T21:35:59Z

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