gpt4 book ai didi

gcc - 为什么objdump的汇编编码不同?

转载 作者:行者123 更新时间:2023-12-04 23:04:01 24 4
gpt4 key购买 nike

我正在读这篇文章article关于位置无关代码,我遇到了这个函数的汇编列表。

0000043c <ml_func>:
43c: 55 push ebp
43d: 89 e5 mov ebp,esp
43f: e8 16 00 00 00 call 45a <__i686.get_pc_thunk.cx>
444: 81 c1 b0 1b 00 00 add ecx,0x1bb0
44a: 8b 81 f0 ff ff ff mov eax,DWORD PTR [ecx-0x10]
450: 8b 00 mov eax,DWORD PTR [eax]
452: 03 45 08 add eax,DWORD PTR [ebp+0x8]
455: 03 45 0c add eax,DWORD PTR [ebp+0xc]
458: 5d pop ebp
459: c3 ret

0000045a <__i686.get_pc_thunk.cx>:
45a: 8b 0c 24 mov ecx,DWORD PTR [esp]
45d: c3 ret

但是,在我的机器(gcc-7.3.0、Ubuntu 18.04 x86_64)上,我得到的结果略有不同:

0000044d <ml_func>:
44d: 55 push %ebp
44e: 89 e5 mov %esp,%ebp
450: e8 29 00 00 00 call 47e <__x86.get_pc_thunk.ax>
455: 05 ab 1b 00 00 add $0x1bab,%eax
45a: 8b 90 f0 ff ff ff mov -0x10(%eax),%edx
460: 8b 0a mov (%edx),%ecx
462: 8b 55 08 mov 0x8(%ebp),%edx
465: 01 d1 add %edx,%ecx
467: 8b 90 f0 ff ff ff mov -0x10(%eax),%edx
46d: 89 0a mov %ecx,(%edx)
46f: 8b 80 f0 ff ff ff mov -0x10(%eax),%eax
475: 8b 10 mov (%eax),%edx
477: 8b 45 0c mov 0xc(%ebp),%eax
47a: 01 d0 add %edx,%eax
47c: 5d pop %ebp
47d: c3 ret

我发现的主要区别在于 mov 指令的语义。在上面的 list 中,mov ebp,esp 实际上将 esp 移动到 ebp,而在下面的 list 中,mov %esp,% ebp 做同样的事情,但操作数的顺序不同。

这非常令人困惑,即使我必须编写手写汇编代码。总而言之,我的问题是(1)为什么我对相同的指令有不同的汇编表示形式,以及(2)在编写汇编代码时我应该使用哪一种表示形式(例如使用 __asm(:::); )

最佳答案

obdjump 默认为 -Matt AT&T 语法(如您的第二个代码块)。请参阅 。标签 wiki 有一些有关语法差异的信息: https://stackoverflow.com/tags/att/infohttps://stackoverflow.com/tags/intel-syntax/info

这两种语法都具有相同的限制,这些限制是由机器本身可以执行的操作以及机器代码中可编码的内容所施加的。它们只是在文本中表达这一点的不同方式。


使用 objdump -d -Mintel 获取 Intel 语法。我在 .bashrc 中使用 alias disas='objdump -drwC -Mintel',因此我可以 disas foo.o 并获得我想要的格式,打印重定位(对于理解非链接的 .o 很重要),长指令无需换行,并且 C++ 符号名称被分解。


在内联汇编中,您可以使用任一语法,只要它符合编译器的期望即可。默认是 AT&T,我建议使用它来与 clang 兼容。也许有办法,但 clang 的工作方式与使用 -masm=intel 的 GCC 不同。

此外,AT&T 基本上是 x86 上 GNU C 内联汇编的标准,这意味着您不需要特殊的构建选项即可使代码正常工作。

但是您可以使用 gcc -masm=intel 来编译在 asm 语句中使用 Intel 语法的源文件。如果您不关心 clang,这适合您自己使用。


如果您正在为 header 编写代码,您可以使用方言替代方案使其在 AT&T 和 Intel 语法之间可移植,至少对于 GCC 来说是这样:

static inline
void atomic_inc(volatile int *p) {
// use __asm__ instead of asm in headers, so it works even with -std=c11 instead of gnu11
__asm__("lock {addl $1, %0 | add %0, 1}": "+m"(*p));
// TODO: flag output for return value?
// maybe doesn't need to be asm volatile; compilers know that modifying pointed-to memory is a visible side-effect unless it's a local that fully optimizes away.
// If you want this to work as a memory barrier, use a `"memory"` clobber to stop compile-time memory reordering. The lock prefix provides a runtime full barrier
}

gcc/clang 的源+asm 输出 on the Godbolt compiler explorer .

使用g++ -O3(默认或-masm=att),我们得到

atomic_inc(int volatile*):
lock addl $1, (%rdi) # operand-size is from my explicit addl suffix
ret

使用g++ -O3 -masm=intel,我们得到

atomic_inc(int volatile*):
lock add DWORD PTR [rdi], 1 # operand-size came from the %0 expansion
ret

clang 适用于 AT&T 版本,但因 -masm=intel(或 -mllvm --x86-asm-syntax=intel-mllvm --x86-asm-syntax=intel)而失败code> 这意味着),因为这显然只适用于 LLVM 发出的代码,而不适用于前端如何填充 asm 模板。

clang 错误消息是:

<source>:4:13: error: unknown use of instruction mnemonic without a size suffix
__asm__("lock {addl $1, %0 | add %0, 1}": "+m"(*p));
^
<inline asm>:1:2: note: instantiated into assembly here
lock add (%rdi), 1
^
1 error generated.

它选择了“Intel”语法替代方案,但仍然使用 AT&T 内存操作数填充模板。

关于gcc - 为什么objdump的汇编编码不同?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/55193397/

24 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com