No, that is feasible. When running an expression we should be calling a static function that is something like:
ExpressionParser *parser = ExpressionParser::FindPlugin(ExecutionContext &exe_ctx); The execution context contains a target, process, thread and frame, and the frame contains the current location so we can check our the language of the compile unit. Greg On Jan 16, 2014, at 11:54 AM, Michael Woerister <[email protected]> wrote: > Ignoring time and effort, do you see any conceptual obstacles in supporting > different source languages (expression parsers, type representations) as > plugins like new object file or symbol parsers? > > On 16.01.2014 19:34, Greg Clayton wrote: >> To follow up: >> >> ClangASTType should really be renamed CompilerType. And then everyone can >> place their types into this class and all type inspection will just work. >> >> Each new language that doesn't use clang for its compiler would need a new >> expression parser that will need to know how to play with the CompilerType. >> We will probably need to add accessors to ClangASTType like: >> >> bool ClangASTType::IsClangType() const; >> bool ClangASTType::IsJuliaType() const; >> bool ClangASTType::IsRustType() const; >> >> Then the expression parsers would need to make sure to check any types they >> find via lookups to make sure the ClangASTType is the correct type. >> >> On Jan 16, 2014, at 10:02 AM, Keno Fischer <[email protected]> >> wrote: >> >>> Over in the Julia (julialang.org), we're interested in this too. Our >>> currently planned approach is to have a custom frontend to LLDB that uses >>> LLDB's C++ API to do the heavy lifting, so I'm not sure how much of this is >>> relevant. Nevertheless, it would be great to coordinate any efforts on this >>> front. >>> >>> >>> On Thu, Jan 16, 2014 at 12:52 PM, Greg Clayton <[email protected]> wrote: >>> >>> On Jan 16, 2014, at 8:04 AM, Michael Woerister <[email protected]> >>> wrote: >>> >>>> On 13.01.2014 15:04, Michael Woerister wrote: >>>>> Hi everyone, >>>>> I was wondering if it is a goal of LLDB to allow for supporting >>>>> programming languages other C/C++ and Objective-C? I've been browsing the >>>>> source code a bit and found that references to clang::Type are hardwired >>>>> into lldb::Type. Is there an extension path that allows to sidestep Clang >>>>> and use one's own type representation? Is it even feasible to try and >>>>> support non-Clang languages within LLDB's architecture? That would be >>>>> very interesting to me. >>>>> >>>>> Thanks for reading! >>>>> -Michael >>>>> _______________________________________________ >>>>> lldb-dev mailing list >>>>> [email protected] >>>>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev >>>> Nobody care to comment? Let me elaborate a bit on my reasons for asking. >>>> Since last summer I've been working on debuginfo generation for the Rust >>>> compiler (www.rust-lang.org). As the Rust compiler is LLVM based this >>>> worked out pretty well and we produce DWARF good enough to satisfy basic >>>> debugging needs. >>> You say you have LLVM creating Rust binaries, did you write a whole new >>> backend? >>> >>> We currently use clang as our expression parser, but that doesn't mean we >>> can't use a different expression parser for other languages. >>> >>>> However, obviously debuggers don't recognize Rust yet and print out values >>>> in the wrong syntax among other things. Some of this can be alleviated >>>> with Python extensions in LLDB and GDB, but the information available >>>> through those APIs seems to be limited (eg. it seems hard get modifiers, >>>> such as 'const' or 'volatile'). Also it would be great to allow for >>>> parsing Rust expressions in the debugger, call functions, in short: make >>>> Rust a first-class citizen of the given debugger. I'm currently trying to >>>> find out what the possibilities in this area are. >>> You would need to do the following: >>> >>> 1 - Modify ClangASTType() to support different types. Right now it contains >>> to member variables: >>> >>> >>> lldb::clang_type_t m_type; >>> clang::ASTContext *m_ast; >>> >>> But this could easily be expanded to contain other things. The "m_ast" >>> could be switched over to a pointer union so it could be a >>> "clang::ASTContext" or a "rust::ASTContext" (or how ever you want to >>> represent your type. Then "m_type" can be any "void *" that can represent >>> types in your new type system. >>> >>> 2 - Modify the expression parser to recognize the current language of the >>> current compile and use your new expression parser that knows how to >>> interact with the new type in ClangASTType() >>> >>> #1 is pretty easy (few weeks), #2 is a big job (few months) unless the >>> expression parser is still the clang expression parser we are using today. >>> >>> >>>> GDB seems to have a story for supporting new source languages but for LLDB >>>> I couldn't find anything about the topic yet. It would be great if >>>> somebody could elaborate on this, even if only saying "not a goal for >>>> LLDB" or "too early to ask for something like this". >>> LLDB is ready for this, we just haven't done it yet. Let me know if you >>> have any other questions. >>> >>> Greg >>> >>>> Thanks again, >>>> Michael >>>> _______________________________________________ >>>> lldb-dev mailing list >>>> [email protected] >>>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev >>> _______________________________________________ >>> lldb-dev mailing list >>> [email protected] >>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev >>> >> _______________________________________________ >> lldb-dev mailing list >> [email protected] >> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev > > _______________________________________________ > lldb-dev mailing list > [email protected] > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev _______________________________________________ lldb-dev mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
