[lldb-dev] Custom expression evaluation target options
Luke Drummond via lldb-dev
lldb-dev at lists.llvm.org
Thu Dec 3 08:44:20 PST 2015
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.
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
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
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
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.
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
Codeplay Software Ltd.
Level C, Argyle House, 3 Lady Lawson St, Edinburgh, EH3 9DR
More information about the lldb-dev