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

[Jason Molenda via lldb-commits]

> 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)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: repo.tar
Type: application/x-tar
Size: 10240 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20180313/5440a3a4/attachment-0001.tar>
-------------- next part --------------



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.

J