Re: [Lldb-commits] [lldb] r327356 - [ExpressionParser] Fix crash when evaluating invalid expresssions.

2018-03-20 Thread Greg Clayton via lldb-commits
Thanks for fixing this is the right way and taking the time! Greg > On Mar 20, 2018, at 12:49 PM, Davide Italiano via lldb-commits > wrote: > > Fixed in a nicer/cleaner way (that doesn't regress the current > behavior), thank you everybody for your excellent

Re: [Lldb-commits] [lldb] r327356 - [ExpressionParser] Fix crash when evaluating invalid expresssions.

2018-03-20 Thread Davide Italiano via lldb-commits
Fixed in a nicer/cleaner way (that doesn't regress the current behavior), thank you everybody for your excellent feedback! davide@Davidinos-Mac-Pro ~/w/l/llvm-project-20170507> git llvm push Pushing 1 commit: 8875fcce772 [ExpressionParser] Re-implement r327356 in a less disruptive way. Sending

Re: [Lldb-commits] [lldb] r327356 - [ExpressionParser] Fix crash when evaluating invalid expresssions.

2018-03-15 Thread Davide Italiano via lldb-commits
On Wed, Mar 14, 2018 at 1:52 AM, Pavel Labath wrote: > I'm not familiar with all of the magic we do when we synthesize clang Decls, > but I feel I should point out that we can't get out of business of > sanity-checking the declarations we inject into clang. The reason for that

Re: [Lldb-commits] [lldb] r327356 - [ExpressionParser] Fix crash when evaluating invalid expresssions.

2018-03-14 Thread Pavel Labath via lldb-commits
I'm not familiar with all of the magic we do when we synthesize clang Decls, but I feel I should point out that we can't get out of business of sanity-checking the declarations we inject into clang. The reason for that is, even if we had debug info for operator==, the debug info itself could

Re: [Lldb-commits] [lldb] r327356 - [ExpressionParser] Fix crash when evaluating invalid expresssions.

2018-03-13 Thread Davide Italiano via lldb-commits
On Tue, Mar 13, 2018 at 2:43 PM, Jason Molenda wrote: > > >> On Mar 13, 2018, at 11:51 AM, Davide Italiano via lldb-commits >> wrote: >> >> We had the report of a crash where lldb was setting a conditional >> breakpoint on an invalid condition

Re: [Lldb-commits] [lldb] r327356 - [ExpressionParser] Fix crash when evaluating invalid expresssions.

2018-03-13 Thread Jason Molenda via lldb-commits
> On Mar 13, 2018, at 11:51 AM, Davide Italiano via lldb-commits > wrote: > > We had the report of a crash where lldb was setting a conditional > breakpoint on an invalid condition (CGRect == pointer, which is, > ill-formed). > The symbol-based resolution of lldb

Re: [Lldb-commits] [lldb] r327356 - [ExpressionParser] Fix crash when evaluating invalid expresssions.

2018-03-13 Thread Davide Italiano via lldb-commits
On Tue, Mar 13, 2018 at 10:56 AM, Greg Clayton wrote: > > > On Mar 13, 2018, at 10:25 AM, Davide Italiano via lldb-commits > wrote: > > On Tue, Mar 13, 2018 at 9:59 AM, Frédéric Riss via lldb-commits > wrote: > > > >

Re: [Lldb-commits] [lldb] r327356 - [ExpressionParser] Fix crash when evaluating invalid expresssions.

2018-03-13 Thread Davide Italiano via lldb-commits
On Tue, Mar 13, 2018 at 11:17 AM, Greg Clayton wrote: > If you check the expression log, you will see the printf() function > declaration and any others we add: > > (lldb) log enable lldb expr > (lldb) 2+3 > > ... > #ifndef NULL > #define NULL (__null) > #endif > #ifndef Nil

Re: [Lldb-commits] [lldb] r327356 - [ExpressionParser] Fix crash when evaluating invalid expresssions.

2018-03-13 Thread Greg Clayton via lldb-commits
If you check the expression log, you will see the printf() function declaration and any others we add: (lldb) log enable lldb expr (lldb) 2+3 ... #ifndef NULL #define NULL (__null) #endif #ifndef Nil #define Nil (__null) #endif #ifndef nil #define nil (__null) #endif #ifndef YES #define YES

Re: [Lldb-commits] [lldb] r327356 - [ExpressionParser] Fix crash when evaluating invalid expresssions.

2018-03-13 Thread Davide Italiano via lldb-commits
On Tue, Mar 13, 2018 at 10:57 AM, Greg Clayton wrote: > > >> On Mar 13, 2018, at 10:37 AM, Davide Italiano via lldb-commits >> wrote: >> >> An alternative proposed by Fred which is an OK middle ground IMHO is >> that of not inserting a decl for

Re: [Lldb-commits] [lldb] r327356 - [ExpressionParser] Fix crash when evaluating invalid expresssions.

2018-03-13 Thread Greg Clayton via lldb-commits
> On Mar 13, 2018, at 10:37 AM, Davide Italiano via lldb-commits > wrote: > > An alternative proposed by Fred which is an OK middle ground IMHO is > that of not inserting a decl for the unmangled name, but treat this > symbol always as-it-is. > i.e. if we have a

Re: [Lldb-commits] [lldb] r327356 - [ExpressionParser] Fix crash when evaluating invalid expresssions.

2018-03-13 Thread Greg Clayton via lldb-commits
> On Mar 13, 2018, at 10:25 AM, Davide Italiano via lldb-commits > wrote: > > On Tue, Mar 13, 2018 at 9:59 AM, Frédéric Riss via lldb-commits > > wrote: >> >> >>> On Mar 12, 2018, at 6:40 PM,

Re: [Lldb-commits] [lldb] r327356 - [ExpressionParser] Fix crash when evaluating invalid expresssions.

2018-03-13 Thread Davide Italiano via lldb-commits
An alternative proposed by Fred which is an OK middle ground IMHO is that of not inserting a decl for the unmangled name, but treat this symbol always as-it-is. i.e. if we have a symbol _Znwm in some object, we don't insert a decl for `operator new(unsigned long)` but for _Znwm itself. Greg,

Re: [Lldb-commits] [lldb] r327356 - [ExpressionParser] Fix crash when evaluating invalid expresssions.

2018-03-13 Thread Davide Italiano via lldb-commits
On Tue, Mar 13, 2018 at 9:59 AM, Frédéric Riss via lldb-commits wrote: > > >> On Mar 12, 2018, at 6:40 PM, Davide Italiano via lldb-commits >> wrote: >> >> Author: davide >> Date: Mon Mar 12 18:40:00 2018 >> New Revision: 327356 >> >>

Re: [Lldb-commits] [lldb] r327356 - [ExpressionParser] Fix crash when evaluating invalid expresssions.

2018-03-13 Thread Greg Clayton via lldb-commits
I agree with Jason, we shouldn't be looking at magic naming and making assumptions. What is the name is a C function that starts with _Z. Both of Jason's examples below should work. Sometimes we only have symbol tables and if people are able to only get to the C++ function via a mangled name,

Re: [Lldb-commits] [lldb] r327356 - [ExpressionParser] Fix crash when evaluating invalid expresssions.

2018-03-13 Thread Jason Molenda via lldb-commits
> On Mar 12, 2018, at 7:52 PM, Davide Italiano via lldb-commits > wrote: > > On Mon, Mar 12, 2018 at 7:27 PM, Jason Molenda via lldb-commits > wrote: >> FWIW, we'll definitely get pushback about >> >>> Now you can't do in lldb

Re: [Lldb-commits] [lldb] r327356 - [ExpressionParser] Fix crash when evaluating invalid expresssions.

2018-03-13 Thread Frédéric Riss via lldb-commits
> On Mar 12, 2018, at 6:40 PM, Davide Italiano via lldb-commits > wrote: > > Author: davide > Date: Mon Mar 12 18:40:00 2018 > New Revision: 327356 > > URL: http://llvm.org/viewvc/llvm-project?rev=327356=rev > Log: > [ExpressionParser] Fix crash when evaluating

Re: [Lldb-commits] [lldb] r327356 - [ExpressionParser] Fix crash when evaluating invalid expresssions.

2018-03-12 Thread Davide Italiano via lldb-commits
On Mon, Mar 12, 2018 at 7:27 PM, Jason Molenda via lldb-commits wrote: > FWIW, we'll definitely get pushback about > >> Now you can't do in lldb anymore >> (lldb) call _Zsomethingsomething(1,2,3) > > > There are clever users of lldb, often working at assembly language

Re: [Lldb-commits] [lldb] r327356 - [ExpressionParser] Fix crash when evaluating invalid expresssions.

2018-03-12 Thread Jason Molenda via lldb-commits
FWIW, we'll definitely get pushback about > Now you can't do in lldb anymore > (lldb) call _Zsomethingsomething(1,2,3) There are clever users of lldb, often working at assembly language level without any symbolic information, who are able to correctly call a C++ mangled function by hand.