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 feedback!
>
> davide@Davidinos-Ma
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
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
> is, even if we had
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
descri
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 (CGRect == pointer, which is,
>> ill-formed).
>> The
> 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 was picking a random operator=
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:
>
>
>
> On Mar 12, 2018, at 6:40 PM, Davide Italiano via lldb-commits
> wrote:
>
> Aut
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
> #define Nil (__null
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 ((BO
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 the unmangled name, but treat this
>> symbol always
> 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 symbol _Znwm in some object, we
> 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
> mailto:lldb-commits@lists.llvm.org>> wrote:
>>
>>
>>> On Mar 12, 2018, at 6:40 PM, Davide Italiano via lldb-commits
>>> wrote:
>>>
>>> Author: da
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, Jason
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
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=327356&view=rev
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, t
> 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 anymore
>>> (lldb) call _Zsomethingsomething(1,2,3)
>>
>>
>> Th
> 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&view=rev
> Log:
> [ExpressionParser] Fix crash when evaluating invalid expresssions.
>
>
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 level
> without any symbolic
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. It's
19 matches
Mail list logo