Expressions on baremetal target


We are debugging a baremetal application using LLDB which is connected to a remote target (supporting GDB remote protocol).

We are able to execute expressions involving global and frame variables such as:

(lldb) expr var+4

However, LLDB is unable to execute expressions involving function calls.

(lldb) expr (int) bar(1,2)

error: Can’t run the expression locally: Interpreter doesn’t handle one of the expression’s opcodes

Function bar is defined as int bar(int, int).

The expression execution_policy is set to eExecutionPolicyNever as CanJIT() returns false for baremetal applications.

This is because JIT is disabled for static dynamic loader targets.

The IRInterpreter::CanInterpret returns false as it fails to interpret call instruction (call to ‘bar’ is not an intrinsic).

Could you please help us on this?



Hi Bhushan

We ran into this problem whilst doing the Hexagon DSP support in LLDB.

This review was up () but is now stale without reviewers. Basically we added the ability to the IR interpreter to call functions on the target using a threadplan which manipulated the stack and registers to call functions and capture any return values, which works well on bare metal without ability to jit. Maybe the patches can be of help to you. I doubt they would apply cleanly now given the length of time since it was uploaded. It’s a valuable feature, but priorities on the list were elsewhere :slight_smile: Colin


looking at that patch, it looks like it has some great ideas!

I have a few concerns:

(a) it looks like it is not 64-bit clean, it assumes that everything it works with is 4 bytes wide;
(b) it’s got some assertions where I’d prefer proper error handling;
(c) it relies on the PrepareTrivialCall infrastructure which only handles simple argument types; and
(d) while it tries hard to ensure that strings are exported into the target’s memory, it doesn’t have any provisions for moving other data that the expression allocated.

While I’d defer to Jim Ingham for comment on the thread plan aspect, I think the interpreter side looks like it has potential. Also that part might still apply. I’m fine with ironing out (c) and (d) in tree, working with the LLVM folks to get better solutions, but (a) and (b) and a style nit here and there would currently block integration from my point of view. Hopefully you agree that those are the easy bits to fix.

If you can resurrect this patch against recent ToT, I’m happy to be a reviewer.


Hey Sean,

Yeah, it’s a nice feature - even if it only works with basic types as you noticed. I’ll look to fix up the concerns you’ve identified. We’re working on a few other hexagon-related patches to put into review, so I’ll add this one to the list. We’ll add you as a reviewer when it happens - thanks!


A note on this – we’re using this internally for Hexagon, and it works – at least for the fairly simple calls I’ve tried J.