I agree with Jason, we shouldn't be looking at magic naming and making assumptions. What is the name is a C function that starts with _Z.
Both of Jason's examples below should work. Sometimes we only have symbol tables and if people are able to only get to the C++ function via a mangled name, they should be able to use it. Greg > On Mar 13, 2018, at 10:13 AM, Jason Molenda via lldb-commits > <lldb-commits@lists.llvm.org> wrote: > > > >> 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 <mailto:lldb-commits@lists.llvm.org> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits > <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