This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PP?] Re: [PATCH] Use -qualified flag when setting temporary breakpoint in start command
On Tue, Apr 09, 2019 at 06:02:09PM -0400, Simon Marchi wrote:
> On 2019-04-09 13:12, André Pönitz wrote:
> > I wonder whether there's still a chance to have a(n additional) way
> > to specify the effect of -qualified using a syntax that is the same
> > across GDB versions.
> >
> > I have pretty much the same effect like Simon for 'start' for a feature
> > 'Break on abort()' in 'my' IDE, that post-8.1 triggers on any function
> > called 'abort'.
> >
> > Even with the Python interface there seems to be no way to have
> > a single way to set the breakpoint short of having Pre/Post81Breakpoint
> > classes using different base constructors and try:/except...:
> > to find the matching version.
> >
> > To be honest, I am tempted to call the whole pattern matching on
> > function names a mis-feature. C++ name resolution is not really
> > compatible with regexps, so at the very least when naming the
> > global explicitly ('b ::abort') there should be no match on
> > 'struct Foo { void abort() {} };'
>
> There is no pattern matching/regexp happening here. The wild matching
> introduced in 8.1 just means that the identifier that you look up may be at
> any level, under some namespace or class.
Ok. Sorry for not having checked the implementation before writing
the mail.
I have some sympathy for the 'ignore namespaces' case as I am living in a
world of user(!)-configurable namespaces myself, but I still do not see
much benefit in treating 'some_class::bar()' and 'some_ns::bar()' "the same"
under "default" circumstances. Ignoring the static some_class case these
are pretty much always really different functions.
> Unless I am missing something, I believe that 'b ::abort' should do what you
> want, and the current behavior is simply buggy.
Buggy or not, it's certainly intentionally changed user-visible behaviour
without good way on the user side to distinguish between the versions.
This makes maintaining GDB
I cannot reasonbly say "without any way" as one apparently can distinguish the
versions by trying to instantiate gdb.Breakpoint sub-classes with different
constructors and tell from the failures on which side of the fence one lives,
but that's, erm...
Anyway, mileage varies, and I'll rest my case, and remain happy enough that this
doesn't happen very often.
Andre'