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

[Jason Molenda via lldb-commits]

> On Mar 12, 2018, at 7:52 PM, Davide Italiano via lldb-commits <lldb-commits at lists.llvm.org> wrote:
> 
> On Mon, Mar 12, 2018 at 7:27 PM, Jason Molenda via lldb-commits
> <lldb-commits at lists.llvm.org> wrote:
>> FWIW, we'll definitely get pushback about
>> 
>>> Now you can't do in lldb anymore
>>> (lldb) call _Zsomethingsomething(1,2,3)
>> 
>> 
>> There are clever users of lldb, often working at assembly language level without any symbolic information, who are able to correctly call a C++ mangled function by hand.  It's not something I'd want to do personally, but I'd be mad at my debugger if it gave me an error message when I told it what to do.
>> 
>> 
> 
> I understand your point. We had several discussions about this and I
> was really reluctant to push this change to begin with.

Sorry for missing out on the earlier discussions and coming in to this late.


I don't understand exactly what's going on here.  If I have a program like

extern "C"  void takefive_c(int five) {};
void takefive_cpp(int five) {}
int main () {}

compiled without debug information, I can do

(lldb) p (void)takefive_c(5)
(lldb) p (void)_Z12takefive_cppi(5)


why is the second expression any different than the first?  I'm calling a symbol name without any debug information, prototypes, or types at all.




> I thought about alternatives and basically I ended up realizing that
> maintaining the invariants that the AST wants Is crazytown.
> You don't need to squint too hard to see that basically nobody using
> clang does this.
> All the clang tools prefer to insert text in a source file and reparse
> it because modifying the AST in place is hard.
> It's funny that they do that because the changes they make are
> generally fairly localized, but nobody really understands what Sema
> really wants (note, the invariants are hardcoded in the Sema path).
> Injecting a generic decl in the context and crossing finger is not
> really great IMHO. It causes crashes, which, from what I understand in
> the lldb world are much worse than not being able to display
> informations (from what I can see the mantra of lldb is "the debugger
> should never crash").
> 
> So, yes, this patch is in some way picking one of two poisons. If we
> want to take a look at this again (i.e. we consider it important
> enough), then the interaction between debugger and compiler needs to
> be rethought to inject something less terrible than a generic decl.
> This is, needless to say, fairly hard because in this case you're
> getting the symbols from a Mach-O object file, so all the state you
> have is a mangled symbol name, which doesn't contain enough
> information to reconstruct the whole context. In swift we can do
> better because we have a fully-fledged type reconstruction mechanism
> (swift::ide::GetTypeFromMangledSymbolName()), and even there, we
> experienced a fair amount of pain because the path still has issues
> that need to be shaken.
> 
> tl;dr if somebody wants to rewrite this, I'll be very happy to support
> this , but I don't see a real reason to keep the feature in an
> half-baked state.
> 
> Best,
> 
> --
> Davide
> _______________________________________________
> lldb-commits mailing list
> lldb-commits at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits