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

[Greg Clayton via lldb-commits]

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 at lists.llvm.org> wrote:
> 
> 
> 
>> 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
> 
> _______________________________________________
> lldb-commits mailing list
> lldb-commits at lists.llvm.org <mailto:lldb-commits at lists.llvm.org>
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits <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/20180313/58ede85b/attachment-0001.html>