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

[Pavel Labath via lldb-commits]

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

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?

cheers,
pl

On Wed, 14 Mar 2018 at 01:25, Davide Italiano via lldb-commits <
lldb-commits at lists.llvm.org> wrote:

> On Tue, Mar 13, 2018 at 2:43 PM, Jason Molenda <jmolenda at apple.com> wrote:
> >
> >
> >> 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)
> >
> >
> >
> >
> >
> > 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 at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20180314/d0c41144/attachment.html>