相关疑难解决方法(0)

在x86-64 Tour of Intel Manuals中,我读到了

也许最令人惊讶的事实是,诸如MOV EAX, EBX自动将指令的高32位归零的指令RAX.

同一来源引用的英特尔文档(3.4.1.1 64位手动基本架构中的通用寄存器)告诉我们:

• 64位操作数在目标通用寄存器中生成64位结果.
• 32位操作数生成32位结果,在目标通用寄存器中零扩展为64位结果.
• 8位和16位操作数生成8位或16位结果.目标通用寄存器的高56位或48位(分别)不会被操作修改.如果8位或16位操作的结果用于64位地址计算,则将寄存器显式符号扩展为完整的64位.

在x86-32和x86-64汇编中,16位指令如

mov ax, bx

不要表现出这种"奇怪"的行为,即eax的上层词被归零.

因此:引入这种行为的原因是什么？乍一看似乎不合逻辑(但原因可能是我习惯了x86-32汇编的怪癖).

int 0x80在Linux上总是调用32位ABI,不管是什么模式,这就是所谓的:在args ebx,ecx...和系统调用号的/usr/include/asm/unistd_32.h.(或者在没有编译的64位内核上崩溃CONFIG_IA32_EMULATION).

64位代码应该使用syscall,从呼叫号码/usr/include/asm/unistd_64.h,并在args rdi,rsi等见什么调用约定UNIX和Linux系统上的i386和x86-64调用.如果您的问题被打上这样一个重复的,看你怎么说链接,细节应当使32位或64位代码的系统调用. 如果你想了解到底发生了什么,请继续阅读.

sys_write系统调用比syscall系统调用快,所以使用本机64位,int 0x80除非你正在编写多格式机器代码,当执行32或64位时运行相同的机器代码.(syscall始终以32位模式返回,因此它在64位用户空间中没有用,尽管它是有效的x86-64指令.)

相关:Linux系统的权威指南(在x86上)调用如何进行sysenter或int 0x8032位系统调用,或sysenter64位系统调用,或调用vDSO进行"虚拟"系统调用syscall.加上有关系统调用的背景知识.

使用gettimeofday可以编写将以32位或64位模式组合的内容,因此它可以int 0x80在微基准测试结束时使用.

标准化函数和系统调用约定的官方i386和x86-64 System V psABI文档的当前PDF文件链接自https://github.com/hjl-tools/x86-psABI/wiki/X86-psABI.

有关初学者指南,x86手册,官方文档和性能优化指南/资源,请参阅x86标记wiki.

但是,由于人们不断发布与使用代码的问题exit_group()在64位代码,或不小心建立64位二进制文件从源代码对于32位写的,我不知道是什么确切不会对当前的Linux怎样呢？

是否int 0x80保存/恢复所有的64位寄存器？它会将任何寄存器截断为32位吗？如果传递上半部分非零的指针args会发生什么？

如果你传递32位指针它是否有效？

我用谷歌搜索了这个问题，一些答案声明 WSL 2 现在支持 ELF 32 程序。

然而，在wsl2 Debian/Ubuntu发行版上的简单测试没有通过。

这是我的测试：

// install run-time
sudo dpkg --add-architecture i386
sudo apt-get update
// install build tools
sudo apt install build-essential
sudo apt install gcc-multilib
// build
gcc helloworld.c  -m32
// run!
./a.out
bash: ./a.out: cannot execute binary file: Exec format error

指：

• Exec 格式错误 32 位可执行 Windows Linux 子系统？
• https://superuser.com/questions/1407730/run-32-bit-application-on-ubuntu-on-windows-subsystem-for-linux/1407818#1407818