> 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)
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.
J_______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
