On Tue, Mar 13, 2018 at 2:43 PM, Jason Molenda <jmole...@apple.com> wrote:
>
>
>> 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)
>
>
>
>
>
> 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
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
