> On Mar 12, 2018, at 7:52 PM, Davide Italiano via lldb-commits > <lldb-commits@lists.llvm.org> wrote: > > 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.
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@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits