重新定位R_X86_64_32S针对`.text'在制作共享对象时无法使用

我正在编译一个静态库，它利用了一些内联汇编代码。重新定位R_X86_64_32S针对`.text'在制作共享对象时无法使用

我注意到，当我使用标签为jmp指令：

int foo(){ 

asm volatile 
(
    "mov 0x60(%r8),%r11d\n\t" 
    "jmp *S_401a70\n\t" 
    ... 
    "S_401a70: xor %rax, %rax\n\t" 
    ... 
) 
}

和编译代码到一个静态库具有以下标志：

-Wl,--no-undefined -nostdlib -nodefaultlibs -nostartfiles -L$(SOME_LIBRARY_PATH) \ 
-Wl,--whole-archive -l$(SOME_Library_Name) -Wl,--no-whole-archive \ 
-Wl,-Bstatic -Wl,-Bsymbolic -Wl,--no-undefined \ 
-Wl,-pie,-eenclave_entry -Wl,--export-dynamic \ 
-Wl,--defsym,__ImageBase=0

我会得到一些错误，如：

/usr/bin/ld: Enclave/libtest.o: relocation R_X86_64_32S against `.text' can not be used when making a shared object; recompile with -fPIC

但是，由于我正在编译成一个sta抽象图书馆，我不认为-fPIC是有道理的。我试过了，但它根本不起作用。

这看起来像是gcc assembly extension的问题，但我不确定。任何人都可以点亮这个灯光吗？谢谢！

来源

2017-06-28 computereasy

你是否尝试从'jmp'指令中删除间接（'*'）？这应该是一个相对跳跃，而这看起来像你想要的。 – owacoder

这不是一个工具问题。首先-fPIC只影响C代码。并且以这样的方式影响它：生成的代码将不包含被引用的数据/代码的绝对地址，并且不会依赖它在内存中的自己的地址（这是一个稍微简单的解释）。接下来 - 它与组装内联无关。由于这里的代码是由程序员生成的。如果它是以一种引入绝对地址或引入对其内存位置的依赖性的方式编写的，那么编译器就无法提供帮助。

P.S.即使使用依赖于位置的代码，您也可以构建静态库，但如果有人尝试将其链接到共享库中，它将不会被链接器接受，因为结果共享库应该与位置无关。

来源

2017-06-28 22:30:35 Sergio

大多数我认为这是由于'label'。原因是当我注释掉''jmp * S_401a70 \ n \ t“'时，构建过程就变得正确了。 – computereasy

重新定位R_X86_64_32S针对`.text'在制作共享对象时无法使用

回答

相关问题