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

[Davide Italiano via lldb-commits]

On Tue, Mar 13, 2018 at 2:43 PM, Jason Molenda <jmolenda at apple.com> wrote:
>
>
>> On Mar 13, 2018, at 11:51 AM, Davide Italiano via lldb-commits <lldb-commits at lists.llvm.org> 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==,
>> inserting a generic function decl operator== in the context because it
>> happened to find a matching symbol somewhere in the system.
>>
>> clang expects operator== to have at least one argument, so you end up
>> hitting this assertion in Sema.
>>
>> (lldb) Assertion failed: (i < getNumParams() && "Illegal param #"),
>> function getParamDecl, file
>> /Users/davide/work/llvm-monorepo/llvm-project-20170507/llvm/tools/clang/include/clang/AST/Decl.h,
>> line 2232.
>>
>> So, to answer your question, Greg, I just want lldb to not inject
>> arbitrary C++ func decl. What do you think is the best way of
>> achieving this?
>>
>
>
> I put together a repo case that might help make this clearer (attached)
>
>
>
>
>
> we have a test program with three translation units.  One has C++ methods and was built with debug info ("foo"), one has C++ methods and was built without debug info ("bar").  It tries calling these from lldb:
>
>
> (lldb) p (void)foo('c')
> in foo(char)
> (lldb) p (void)foo(5)
> in foo(int)
> (lldb) p (void)foo(5, 5)
> in foo(int, int)
>
> We had debug info for foo(), called the correct methods.
>
>
> (lldb) p (void)bar('c')
> in bar(char *)
> (lldb) p (void)bar(5)
> in bar(char *)
> (lldb) p (void)bar(5, 5)
> in bar(char *)
>
>
> Here, we have no debug info for bar(), so we grabbed the first bar() method we found and used it for all calls.  This is a problem.
>
>
> (lldb) p (void)_Z3barc('c')
> in bar(char)
> (lldb) p (void)_Z3bari(5)
> in bar(int)
> (lldb) p (void)_Z3barii(5,5)
> in bar(int, int)
>
> Calling the mangled name bar()'s directly works as expected.
>
>
>
> Davide is trying to solve that middle one.  I think the problem he was working on is where we had an expression using operator== and the first "decl" we found of this was in a no-debug-info translation unit, and that randomly chosen operator== was used when there WAS debug info for this operator== in a different translation unit in the process.
>
> The question I have is -- should this even be allowed.  Should you be able to call a C++ method using a demangled name with no debug info?  I'm trying to think of a case where people do this today.  Clearly it does not work correctly today for overloaded functions.  And apparently this could be chosen over a debug info definition that might appear elsewhere in the process?  I didn't try to test that.
>

The debug info version, if present has precedence. The scary bit is
that if you have several symbols matching the decl name (e.g.
`operator==`) lldb will pick a random one [the last one in the list it
builds according to some order]. I don't think this is the expected
behavior, but this is what we have today.

Thanks,

--
Davide