Re: [PATCH 2/6] Introduce `pre_expanded sals'

[Jerome Guitton <guitton@adacore.com>]

Jan Kratochvil (jan.kratochvil@redhat.com):

> With the "new" (for some years) syntax `enable X.Y' ane `disable X.Y' one can
> control which breakpoints are active easily.
> 
> (gdb) break C::C
> Breakpoint 1 at 0x7d1: file ./gdb.cp/re-set-overloaded.cc, line 22.
> Breakpoint 2 at 0x7ba: file ./gdb.cp/re-set-overloaded.cc, line 21. (2 locations)
> warning: Multiple breakpoints were set.
> Use the "delete" command to delete unwanted breakpoints.
> (gdb) disable 2.2
> (gdb) info breakpoints 
> Num     Type           Disp Enb Address            What
> 1       breakpoint     keep y   0x00000000000007d1 in C::C(int) at ./gdb.cp/re-set-overloaded.cc:22
> 2       breakpoint     keep y   <MULTIPLE>         
> 2.1                         y     0x00000000000007ba in C::C() at ./gdb.cp/re-set-overloaded.cc:21
> 2.2                         n     0x00000000000007c4 in C::C() at ./gdb.cp/re-set-overloaded.cc:21
> 
> So that `set multiple-symbols ask' could be removed (probably
> completely incl.  the `cancel' option).


On the contrary, I was wondering if a proper use of the 'ask/all' option
was not precisely the solution here. 'all' would mean: break on any
location that matches the linespec given by the user. If a dll is loaded
that have a location that matches this linespec, then add a new location
for this breakpoint.

On 'ask', you would be asked only for instances that have a different
canonical location, e.g.

(break) C::C
[0] cancel
[1] all
[2] C::C() at ./gdb.cp/re-set-overloaded.cc:21
[3] C::C(int) at ./gdb.cp/re-set-overloaded.cc:22
> 

Choosing 'all' would trigger a multi-location breakpoint and behave
like above.  Selecting some would generate different single-location
breakpoints on the canonical location.

We may even have a command to edit an "all" breakpoint and convert it
into a list of selected single-location breakpoints. It may be easier
to manage than 3-tiers.

(break) breakpoint-edit 1
[0] cancel
[1] all
[2] C::C() at ./gdb.cp/re-set-overloaded.cc:21
[3] C::C(int) at ./gdb.cp/re-set-overloaded.cc:22
> 

Now Tom's question remains: what happens if a unambiguous breakpoint
location becomes ambiguous at dll load? I would suppose that the
appropriate behavior would depend on the 'all/ask' setting: 'all'
means all, so new locations are added, the breakpoints, becomes a
multi-location breakpoint. 'ask' is the main problem. the appropriate
behavior would certainly be to ask the user if the breakpoint should
become 'all' or should be canonicalized. The second option could be a
problem, I suppose. A compromise would be to convert inconditionally to 'all'
with a warning, letting the user edit the breakpoint latter to convert it
into selected single-location breakpoints if he/she wants.


> I find the current two kinds of multiple breakpoints confusing to users (at
> least to myself).

I can only agree. From a user point of view, I feel that homonyms, generics
and inlining should be handled the same way; the distinction that I
need is the 'all/ask' one: either I break on all locations of a
breakpoint (homonyms, generic, inlining, whatever), and add any new
location that a dll load would bring; or I want to select some of them
(presumably one) and have breakpoints on these ones only, and never
add new breakpoints if new occurences are brought by a dll.