[llvm-dev] Multi-architecture (ELF or other) loaders and dynamic linkers available?

ardi via llvm-dev llvm-dev at lists.llvm.org
Wed Apr 4 09:47:02 PDT 2018


On Tue, Apr 3, 2018 at 7:58 PM, Friedman, Eli <efriedma at codeaurora.org> wrote:
> On 4/3/2018 9:33 AM, ardi via llvm-dev wrote:
>>
>> Hi,
>>
>> I'm looking for some sort of "universal loader and dynamic linker",
>> capable of loading in memory an executable (ELF or other, the format
>> is not a requisite at this time) for any of the "major" architectures
>> that have LLVM backends (namely: x86, x86_64, ARM, ARM64, PPC, PPC64,
>> MIPS32, MIPS64), including also relocation, and loading of symbols
>> from dynamic libraries that the executable depends on.
>>
>> The final memory representation of the executable should be "ready to
>> be executed". Before you ask "what OS?, what about syscalls?", let's
>> assume the executable doesn't use any library from the OS, and that
>> there are only a couple of basic syscalls for terminal I/O only, and
>> that such syscalls are already hooked in advance by a tweaked C
>> runtime (i.e.: the executable won't use any syscall protocol, just
>> call hooks in the loader, thanks to the tweaked C runtime).
>>
>> Does LLVM provide any infrastructure ready for doing this?
>
>
> RuntimeDyld is a runtime linker which supports all the architectures you
> listed. And it works cross-target, which might be hard to find otherwise.
> But it's meant for use with objects generated with MCJIT, not arbitrary
> executables, so it might be missing some features you need. See
> https://llvm.org/docs/MCJITDesignAndImplementation.html .

Thanks a lot, Eli. Certainly, it has the functionality I need,
although I don't see it clear how I should create the needed data
objects from an executable file. The MCJIT obviously expects source,
but I guess there must be some way of "fooling" RuntimeDyld by parsing
an executable file (ELF or whatever), loading the proper data, and
creating the MCJIT objects that RuntimeDyld expects.

Anyway, I think RuntimeDyld is what I should use, as I'm using clang
as compiler, so with RuntimeDyld it's quite likely that things will
tend to work more easily than if I mix code from different systems and
compilers...

ardi


More information about the llvm-dev mailing list