[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

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 

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 
offset 0x24).


  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 mailing list