【问题标题】:Where LLVM interpreter is looking for external functions (libraries?)LLVM 解释器在哪里寻找外部函数(库?)
【发布时间】:2017-03-02 19:43:31
【问题描述】:

我正在玩一点 LLVM IR,但我无法解决(在 google 和 doc 的帮助下)LLVM 解释器 lli 正在寻找外部(不是明确定义的函数。我的意思是基本系统函数)。例如,如果我想编写没有依赖关系的简单程序,在 linux 上会在屏幕上写一些东西,我可以这样做:

@message = private constant [12 x i8] c"hello world\0A"
define i32 @puts(i8* %s) {
    call i32 asm sideeffect "movl $$0x2, %edi\0Amovl $$0xC, %edx\0Amovl$$1, %eax\0Asyscall\0A", "=A,{si}"(i8* %s) #1
    ret i32 %1
}
define void @exit(i32 %c) {
    call i32 asm sideeffect "movl $$60, %eax\0Asyscall\0A", "=A,{di}"(i32 %c) #1
    ret void
}
define void @main() {
    getelementptr [12 x i8], [12 x i8]* @message, i64 0, i64 0
    call i32 @puts(i8* %1)
    call void @exit(i32 0)
    ret void
}
define void @_start() {
    call void @main()
    ret void
}

main_start 用于与 ldlli 交叉兼容。所以上面的代码在两者中都是一样的。我可以lli 这个,代码将从main 开始,或者llc 然后ld 它也可以工作,因此代码将按预期从_start 开始。现在如果我写代码:

@formatString = private constant [4 x i8] c"%d\0A\00" 
declare i32 @printf(i8*, ...)
define i32 @main() {
    %d = shl i32 2, 3
    %s = getelementptr [4 x i8], [4 x i8]* @formatString, i64 0, i64 0
    %call = call i32 (i8*, ...) @printf(i8* %s, i32 %d)
    ret i32 0
}

它也适用于lli,但我不能ld 它,因为ld 不知道对printf 的引用,这也是预期的。我可以包含准备ld 参数以使该代码也可以工作,或者简单地使用gcc file.o -o file,但这不是我的意思。我的观点是如何使lli 不包含任何外部库(如libc)并且只运行我的代码,并且可能定义我自己的入口点,所以我可以随意包含任何准备好的libc 或任何其他库,我知道我可以覆盖函数的名称并且应该可以工作,但是我不能确定重写了什么,所以如果 lli 在使用 printf 但未定义时抛出错误,我会很高兴。又或者是我搞错了,lli 无法在这种裸露的环境中发挥作用。

【问题讨论】:

  • 我发现使用lli -entry-function=_start file.ll 我可以选择任何入口点。但仍然不知道如何剥离预加载代码的解释器。有选项-extra-object=<object>,但我找不到禁用默认加载的所有对象的选项。

标签: assembly llvm system-calls llvm-ir


【解决方案1】:

TL;DR:在没有 JIT 的情况下使用 lli 并且可能会工作:

lli -force-interpreter main.bc

更多信息:

通常,这取决于您在后台使用的 JIT 引擎类型(如果有的话)。

我不能谈论 MCJIT (-jit-kind=mcjit),因为我不熟悉它,但我可以向您保证,如果您使用 ORC JIT(-jit-kind=orc-mcjit-jit-kind=orc-lazy),这是不可能的。但是,这仅适用于lli,如果您决定自己使用 ORC,那么您可以控制这种行为。

lli 的上下文中,ORC 不仅会加载您的模块/外部对象,还会加载整个程序的地址空间。这意味着您可以获得所有 libc 和整个 LLVM 本身。

根据您的需要,您可以尝试将lli 真正用作解释器,但由于不再涉及 JIT,它会更慢。

只需添加-force-interpreter 选项,您就可以开始使用了,除了少数例外。这些函数仍然会正常执行:

void Interpreter::initializeExternalFunctions() {
  sys::ScopedLock Writer(*FunctionsLock);
  (*FuncNames)["lle_X_atexit"]       = lle_X_atexit;
  (*FuncNames)["lle_X_exit"]         = lle_X_exit;
  (*FuncNames)["lle_X_abort"]        = lle_X_abort;

  (*FuncNames)["lle_X_printf"]       = lle_X_printf;
  (*FuncNames)["lle_X_sprintf"]      = lle_X_sprintf;
  (*FuncNames)["lle_X_sscanf"]       = lle_X_sscanf;
  (*FuncNames)["lle_X_scanf"]        = lle_X_scanf;
  (*FuncNames)["lle_X_fprintf"]      = lle_X_fprintf;
  (*FuncNames)["lle_X_memset"]       = lle_X_memset;
  (*FuncNames)["lle_X_memcpy"]       = lle_X_memcpy;
}

【讨论】:

  • 不幸的是,我已经尝试过了,也许问题是我使用的是来自官方 git 的全新 LLVM 版本 5.0.0svn。我担心问题是我可以访问解释器为其自身预加载的所有功能。无论如何,谢谢你的回答!
  • 我想知道我是否可以使用mcjit-remote-process 来实现更裸露的环境,但是“标准”远程进程https://github.com/llvm-mirror/llvm/blob/master/tools/lli/ChildTarget/ChildTarget.cpp 看起来并不乐观。
  • 我建议设置您的自定义 JIT 堆栈。非常基本的自定义 lli 相当简单且小巧。如果您需要帮助,请随时给我留言 1101.debian@gmail.com
猜你喜欢
  • 1970-01-01
  • 2023-03-25
  • 2010-10-21
  • 2015-01-16
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2016-08-13
  • 1970-01-01
相关资源
最近更新 更多