On Mon, Mar 12, 2018 at 7:27 PM, Jason Molenda via lldb-commits <lldb-commits@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. 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@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
