<div dir="ltr">I'm not familiar with all of the magic we do when we synthesize clang Decls, but I feel I should point out that we can't get out of business of sanity-checking the declarations we inject into clang. The reason for that is, even if we had debug info for operator==, the debug info itself could describe it's prototype as operator==(...) (due to a compiler bug, corrupt file, or whatever). So we still need to make sure that the declarations we synthesize from debug info don't violate clang's invariants (and that's what we try to do at present, cf. ClangASTContext::CheckOverloadedOperatorParameterCount).<div><br></div><div>So maybe the solution here is not to refuse injecting any declarations without debug info, but instead to make sure that whatever declarations we inject that way satisfy the same validity criteria as the ones we synthesize from the debug info?</div><div><br></div><div>cheers,</div><div>pl</div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, 14 Mar 2018 at 01:25, Davide Italiano via lldb-commits <<a href="mailto:lldb-commits@lists.llvm.org">lldb-commits@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Tue, Mar 13, 2018 at 2:43 PM, Jason Molenda <<a href="mailto:jmolenda@apple.com" target="_blank">jmolenda@apple.com</a>> wrote:<br>
><br>
><br>
>> On Mar 13, 2018, at 11:51 AM, Davide Italiano via lldb-commits <<a href="mailto:lldb-commits@lists.llvm.org" target="_blank">lldb-commits@lists.llvm.org</a>> wrote:<br>
>><br>
>> We had the report of a crash where lldb was setting a conditional<br>
>> breakpoint on an invalid condition (CGRect == pointer, which is,<br>
>> ill-formed).<br>
>> The symbol-based resolution of lldb was picking a random operator==,<br>
>> inserting a generic function decl operator== in the context because it<br>
>> happened to find a matching symbol somewhere in the system.<br>
>><br>
>> clang expects operator== to have at least one argument, so you end up<br>
>> hitting this assertion in Sema.<br>
>><br>
>> (lldb) Assertion failed: (i < getNumParams() && "Illegal param #"),<br>
>> function getParamDecl, file<br>
>> /Users/davide/work/llvm-monorepo/llvm-project-20170507/llvm/tools/clang/include/clang/AST/Decl.h,<br>
>> line 2232.<br>
>><br>
>> So, to answer your question, Greg, I just want lldb to not inject<br>
>> arbitrary C++ func decl. What do you think is the best way of<br>
>> achieving this?<br>
>><br>
><br>
><br>
> I put together a repo case that might help make this clearer (attached)<br>
><br>
><br>
><br>
><br>
><br>
> 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:<br>
><br>
><br>
> (lldb) p (void)foo('c')<br>
> in foo(char)<br>
> (lldb) p (void)foo(5)<br>
> in foo(int)<br>
> (lldb) p (void)foo(5, 5)<br>
> in foo(int, int)<br>
><br>
> We had debug info for foo(), called the correct methods.<br>
><br>
><br>
> (lldb) p (void)bar('c')<br>
> in bar(char *)<br>
> (lldb) p (void)bar(5)<br>
> in bar(char *)<br>
> (lldb) p (void)bar(5, 5)<br>
> in bar(char *)<br>
><br>
><br>
> 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.<br>
><br>
><br>
> (lldb) p (void)_Z3barc('c')<br>
> in bar(char)<br>
> (lldb) p (void)_Z3bari(5)<br>
> in bar(int)<br>
> (lldb) p (void)_Z3barii(5,5)<br>
> in bar(int, int)<br>
><br>
> Calling the mangled name bar()'s directly works as expected.<br>
><br>
><br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
<br>
The debug info version, if present has precedence. The scary bit is<br>
that if you have several symbols matching the decl name (e.g.<br>
`operator==`) lldb will pick a random one [the last one in the list it<br>
builds according to some order]. I don't think this is the expected<br>
behavior, but this is what we have today.<br>
<br>
Thanks,<br>
<br>
--<br>
Davide<br>
_______________________________________________<br>
lldb-commits mailing list<br>
<a href="mailto:lldb-commits@lists.llvm.org" target="_blank">lldb-commits@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits</a><br>
</blockquote></div>