[lldb-dev] Detection of expression language

Sean Callanan scallanan at apple.com
Thu Oct 3 17:16:51 PDT 2013


thanks for having a look at this!

I completely agree that this should happen.  However, there are currently several reasons why making the change you suggest will be hard.

1. SymbolFileDWARF generates CXXRecordDecls for every record declaration.  This is because, in C++, Clang expects all records to use the CXXRecordDecl data structure.  In C, we would have to use plain RecordDecls because Clang in C mode expects that.  I’m not sure the type system would take kindly to having different versions of the same type for C and C++ mode; we’d probably have to have duplicate ClangASTContexts, one in C mode and one in C++ mode.

2. The expression parser itself relies heavily on the C++ reference type for its operation.  The reason you can type “a + b” and have accesses to these relayed as if through a pointer to the versions of a and b in your program is because LLDB uses C++ references behind the scenes.  We do not want people to have to explicitly dereference pointers or anything like that.

The most likely (to my mind!  a Clang developer might have different opinions here :) ) solution to this will probably involve changing Clang itself to allow parsing with C syntax but with C++ semantics under the hood.

If you’re still interested in digging into making this work purely on LLDB’s side, I’d be very excited to see what solutions you come up with.  But be aware that this is much harder than just passing the right language options in the right place.


On Oct 3, 2013, at 5:00 PM, Richard Mitton <richard at codersnotes.com> wrote:

> Hi all,
> The following code fails when asking lldb to run the command "(lldb) expr id"
>    int main() {
>        int id = 4;
>        return 0;
>    }
> The reason is because lldb tries to evaluate the expression as Objective C++, rather than C. And in Objective C++, "id" is a builtin type, and so conflicts with our local variable.
> I'm thinking the correct fix is to evaluate expressions in the language of the current scope, but I just wanted to throw this out there and check before I go off and try to fix it.
> One possible problem of using the current scope's language is that if you had a program that mixed languages (e.g. C++ and ObjC in different files), you wouldn't be able to evaluate any ObjC expressions while you were in a C++ function.
> -- 
> Richard Mitton
> richard at codersnotes.com
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev

More information about the lldb-dev mailing list