Breakpoint matching with -n seems to have gotten too generous

If I have a program like:

class A {
  int AMethod() { return 100; }

class AA {
  int AMethod() { return 200; }

  A myA;
  AA myAA;
  return 0;

Build and run it under lldb, and do:

(lldb) b s -n A::AMethod
Breakpoint 1: 2 locations.
(lldb) break list
Current breakpoints:
1: name = 'A::AMethod', locations = 2
  1.1: where = many_names`A::AMethod() + 8 at many_names.cpp:3:19, address = many_names[0x0000000100000f78], unresolved, hit count = 0
  1.2: where = many_names`AA::AMethod() + 8 at many_names.cpp:8:19, address = many_names[0x0000000100000f88], unresolved, hit count = 0

I think that's wrong. The point of the fuzziness in -n is that you can leave out containing namespaces, or arguments, and we'll still match what you've given us. But IMO that should only expand the search into containing contexts. It is surprising to me that if I specify A::AMethod, I also match the one in the namespace AA. If you wanted to match .*A::AMethod, you could do that with a regular expression. But there's no easy way to not pick up extra breakpoints if you happen to have overlaps like this, so it seems like expanding -n to strstr type matches seems like a bad idea.

I wondered if other folks thought this was desirable behavior.


I was surprised by this behavior too. I wouldn't have expected AA::AMethod to match this.


I agree - I wouldn't expect class AA to be a match for "A::".

Yikes. This is how it is coded currently as we do a search by removing any decl context and then making sure all resulting strings match by starting with "A::AMethod", strip off the basename so we get "AMethod", search for all matches, and then we currently make sure the result contains "A::AMethod". Since "AA::AMethod" contains it, it matches. This is how it has always been.

What we need to do is to ensure there is a decl context boundary ("::" for C++) or the start of the string where the match started.