> On Mar 13, 2018, at 11:51 AM, Davide Italiano via lldb-commits 
> <lldb-commits@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)

Attachment: repo.tar
Description: Unix tar archive

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.

lldb-commits mailing list

Reply via email to