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

[Jan Kratochvil <jan dot kratochvil at redhat dot com>]

On Mon, 18 Apr 2011 20:38:28 +0200, Pedro Alves wrote:
> (ignoring that frontends aren't prepared to have a 
> breakpoint map to more than one source file:line)

I do not address this part in this mail, I do not know much about it.


> Now, do "break A::A".
[...]
>  (gdb) info breakpoints 
>  Num     Type           Disp Enb Address            What
>  1       breakpoint     keep y   <MULTIPLE>         
>  1.1                         y     0x00000000004005d2 in A::A() at foo.cc:33
>  1.2                         y     0x00000000004005ec in A::A() at foo.cc:33
>  1.3                         y     0x00000000004005d2 in A::A(int) at foo.cc:38
>  1.4                         y     0x00000000004005ec in A::A(int) at foo.cc:38
> 
> Now, say I didn't want to A::A(int) overload to break afterall.

If I want to deal with `A::A()' and `A::A(int)' separately I will never type
`break A::A' in the first place but create `break A::A()' and `break A::A(int)'
as two separate breakpoints (or just one of them).


> This is why I proposed in the response to Jan, that if we want
> to group different "_source_ locations" under the same breakpoint,
> we implement it as a 3rd hierarchy, so you'd get:

I agree 3-level hierarchy is the best but I do not think it is practically
worth it, it again creates a feature no normal user is going to use.


> You do "break inline_func".  There are two overloads, so the

While offtopic in general breakpoint on inlined functions do not yet work:
	[Bug breakpoints/10738] Cannot set breakpoint on inlined function


>  (gdb) info breakpoints 
>  Num     Type           Disp Enb Address            What
>  1       breakpoint     keep y   <MULTIPLE>         
>  1.1                         y     "program:name" in foo_func() at blah.c:12
>  1.2                         n     "program:name" in bar_func() at blah.c:20
>  1.3                         y     "program:name" in qux_func() at blah.c:45
> 
> If the program changes, say the 1.2 location disappears, you've now
> confused GDB --- how will it know that 1.3 is supposed to be enabled,
> given that it is now the second location?  (multiple variations of
> this issue).

Besides unspecifically broken reread_symbols during program change normally
update_breakpoint_locations on any nontrivial C++ code finds
HAVE_AMBIGUOUS_NAMES true, uses breakpoint_locations_match and as if the
program really has changed any way the addresses will not match and specific
bp_location enabled-flag will get reset back to enabled anyway.

It also happens with any PIE program but that is more my fault (as its fix in
Fedora is too ugly to be even submitted).


> > I hit this while debugging gdb itself from time to time -- try `break
> > parse_number' and guess where it gets set.
> 
> It's not necessarily a bad thing (and not necessarily a good thing
> either).   If you have a big project, with a bunch of static
> "foo" functions, it's not unreasonable to have "b foo"
> break at the "closest" function with that name in your context.

The problem with GDB is IMO that "your context" is very random, user may not
be much aware there is any context, with the debuggee stopping here and there.


> What would "list parse_number" do if "break parse_number" breaks
> in all the instances of that static function?

A good point, it should error, it needs more specific input.


Thanks,
Jan