[lldb-dev] Custom expression evaluation target options

[Greg Clayton via lldb-dev]

Each expression has a language so we should be able to get the Language* for renderscript:


    lldb_private::Language* language = lldb_private::Language::FindPlugin (m_expr.GetLanguage());

Then you can add a new virtual class on lldb_private::Language that can get any additional compiler flags needed for expressions and just make it work? The renderscript language would set the appropriate ABI flags needed?

Greg


> On Dec 3, 2015, at 8:44 AM, Luke Drummond via lldb-dev <lldb-dev at lists.llvm.org> wrote:
> 
> Hello all
> 
> I've recently tracked down a problem in the expression evaluation engine for lldb, and I'm hoping for some historical context, and possibly some direction on the most appropriate fix.
> 
> ## Problem
> 
> I'd like to be able to set some target options for the JIT when calling `expr myRenderscriptFunction(some_arg)`, so that the JIT compiler generates calling code that matches a given calling convention.
> 
> Expression evaluation on x86 targets for our RenderScript LanguageRuntime requires the JIT to call a RenderScript function with a slightly different ABI than the default detected ABI for the module, (vectors are required to be passed in SSE registers) and there doesn't appear to be a way to configure the `Clang::Compiler` object used in `lldb_private::ClangExpressionParser` to use non-default code-generation options.
> 
> Unfortunately, for now there's no way to get the target options we need in `lldb_private::ClangExpressionParser`. It seems that the constructor for the ClangExpressionParser class hard-codes the target options based on some possibly broken assumptions on the target hardware and ABI available:
> 
> http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp?view=markup#l178
> 
> This has been marked a `TODO` in the source, so I've been working on the assumption that there is no currently implemented way to do this, and have been trying to work out the best way to approach this.
> 
> However, as any new implementation may involve touching codepaths I'm not particularly familiar with - or that other people are actively working on - I'd appreciate if anyone on list can suggest whether:
> 
>   1. There's a better way to do what I need (I hope this is the case).
>   2. If not (1) whether the TODOs/FIXMEs in the current ClangExpressionParser implementation are being worked on already.
> 
> I notice that some of the folks at Imagination gave a similar problem statement on this list, back in April, and it was suggested they encode the processor specific features in the ELF header `e_flags` word (header offset 0x24).
> 
>    http://lists.llvm.org/pipermail/lldb-dev/2015-April/007295.html
> 
> I have checked the LLVM source tree, and it seems that there are no i386 specific flags specified at the present time, so this path doesn't solve the issue either.
> 
>    http://llvm.org/docs/doxygen/html/Support_2ELF_8h_source.html
> 
> These flags seem to be little-used, and a quick search of my current Linux system's lib32 shared objects directory turned up only four files with non-zero e_flags in their header. I've not been able to track down what they mean (grepping GNU binutils was fruitless).
> 
> Any suggestions are welcome.
> 
> All the Best
> 
> Luke
> 
> -- 
> Codeplay Software Ltd.
> Level C, Argyle House, 3 Lady Lawson St, Edinburgh, EH3 9DR
> https://www.codeplay.com
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev