[llvm-dev] LLVM on bare-metal

[Tim Northover via llvm-dev]

Hi Brian,

I'm afraid I can't answer your actual questions, but do have a couple
of comments on the background...

On Thu, 27 Jun 2019 at 09:50, Brian Clarkson via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> LLVM would be responsible for generating
> (optimized, and especially vectorized for NEON) machine code directly on
> the embedded device and it would take care of the relocation and
> run-time linking duties.

That's a much smaller task than what you'd get from embedding all of
LLVM. lldb is probably an example of a program with a similar problem
to you, and it gets by with just a pretty small stub of a
"debugserver" on a device. It does all CodeGen and even prelinking on
the host side, and then transfers binary data across.

The concept is called "remote JIT" in the LLVM codebase if you want to
research it more.

I think the main advantage you'd get from embedding LLVM itself over a
scheme like that would be a certain resilience to updating the RTOS on
the device (it would cope with a function sliding around in memory
even if the host is no longer available to recompile), but I bet there
are simpler ways to do that. The API surface you need to control is
probably pretty small.

> Sharing code in the form of LLVM bytecode
> also seems to sidestep the complex task of setting up a cross-compiling
> toolchain which is something that I would prefer not to have to force my
> users to do.

If you can produce bitcode on the host, you can produce an ARM binary
without forcing the users to install extra stuff. The work involved
would be pretty comparable to what you'd have to do on the RTOS side
anyway (you're unlikely to be running GNU ld against system libraries
on the RTOS), and made slightly easier by the host being more of a
"normal" LLVM environment.

Cheers.

Tim.