Re: [lldb-dev] Breakpoint matching with -n seems to have gotten too generous

2019-08-30 Thread Ted Woodward via lldb-dev

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

> -Original Message-
> From: lldb-dev  On Behalf Of Pavel Labath
> via lldb-dev
> Sent: Friday, August 30, 2019 1:28 AM
> To: Jim Ingham ; LLDB 
> Subject: [EXT] Re: [lldb-dev] Breakpoint matching with -n seems to have
> gotten too generous
> 
> On 30/08/2019 02:33, Jim Ingham via lldb-dev wrote:
> > If I have a program like:
> >
> > class A {
> > public:
> >int AMethod() { return 100; }
> > };
> >
> > class AA {
> > public:
> >int AMethod() { return 200; }
> > };
> >
> > int
> > main()
> > {
> >A myA;
> >AA myAA;
> >myA.AMethod();
> >myAA.AMethod();
> >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[0x00010f78], unresolved, hit count = 0
> >1.2: where = many_names`AA::AMethod() + 8 at many_names.cpp:8:19,
> > address = many_names[0x00010f88], 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.
> 
> pl
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev


Re: [lldb-dev] Breakpoint matching with -n seems to have gotten too generous

2019-08-30 Thread Pavel Labath via lldb-dev

On 30/08/2019 02:33, Jim Ingham via lldb-dev wrote:

If I have a program like:

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

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

int
main()
{
   A myA;
   AA myAA;
   myA.AMethod();
   myAA.AMethod();
   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[0x00010f78], unresolved, hit count = 0
   1.2: where = many_names`AA::AMethod() + 8 at many_names.cpp:8:19, address = 
many_names[0x00010f88], 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.


pl
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev


[lldb-dev] Breakpoint matching with -n seems to have gotten too generous

2019-08-29 Thread Jim Ingham via lldb-dev
If I have a program like:

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

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

int
main()
{
  A myA;
  AA myAA;
  myA.AMethod();
  myAA.AMethod();
  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[0x00010f78], unresolved, hit count = 0 
  1.2: where = many_names`AA::AMethod() + 8 at many_names.cpp:8:19, address = 
many_names[0x00010f88], 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.

Jim


___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev