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@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@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
_______________________________________________
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
