绝对寻址运行时code置换的x86_64code

2023-09-08 01:04:53 作者:ご幽灵め少爷

我目前使用的一些code替代方案,32位,其中code被移动到另一个位置,读取变量和类的指针。由于x86_64的不支持绝对地址,我有麻烦了变量的正确地址为的code中的新位置。详细的问题是,由于裂口相对寻址指令指针地址,它是不是在编译时不同。

I'm currently using some code replace scheme in 32 bit where the code which is moved to another position, reads variables and a class pointer. Since x86_64 does not support absolute addressing I have trouble getting the correct addresses for the variables at the new position of the code. The problem in detail is, that because of rip relative addressing the instruction pointer address is different than at compile time.

那么,有没有一种方法,使用绝对地址,在x86_64的或另一种方式来获得相关变量不是指令指针的地址?

So is there a way to use absolute addressing in x86_64 or another way to get addresses of variables not instruction pointer relative?

是这样的: leaq变量(%% RAX),%% RBX 也将有所帮助。我只想对指令指针不存在依赖关系。

Something like: leaq variable(%%rax), %%rbx would also help. I only want to have no dependency on the instruction pointer.

推荐答案

尝试使用的大的$ C $下x86_64的模型。在海湾合作委员会这可以通过的 -mcmodel =大的选择。编译器将使用64位的绝对地址为code和数据。

Try using the large code model for x86_64. In gcc this can be selected with -mcmodel=large. The compiler will use 64 bit absolute addressing for both code and data.

您还可以增加的 -fno-PIC 的不允许的位置无关code的产生。

You could also add -fno-pic to disallow the generation of position independent code.

编辑:我建立一个小的测试应用程序的 -mcmodel =大的产生的二进制包含像

I build a small test app with -mcmodel=large and the resulting binary contains sequences like

400b81:       48 b9 f0 30 60 00 00    movabs $0x6030f0,%rcx
400b88:       00 00 00 
400b8b:       49 b9 d0 09 40 00 00    movabs $0x4009d0,%r9
400b92:       00 00 00 
400b95:       48 8b 39                mov    (%rcx),%rdi
400b98:       41 ff d1                callq  *%r9

这是一个绝对的64位立即(在此情况下一个地址)的负荷,接着通过间接调用或间接负载。该指令序列

which is a load of an absolute 64 bit immediate (in this case an address) followed by an indirect call or an indirect load. The instruction sequence

moveabs variable, %rbx
addq %rax, %rbx

是等效于一个leaq offset64bit(%RAX),%RBX(不存在),与一些副作用,如标志改变等。

is the equivalent to a "leaq offset64bit(%rax), %rbx" (which doesn't exist), with some side effects like flag changing etc.