我在 u-boot/arch/arm/lib/semihosting.c 中发现了以下一段代码,它使用 bkpt
和其他指令并提供了输入和输出操作数,即使它们没有在 ASM 模板中指定:
static noinline long smh_trap(unsigned int sysnum, void *addr)
{
register long result asm("r0");
#if defined(CONFIG_ARM64)
asm volatile ("hlt #0xf000" : "=r" (result) : "0"(sysnum), "r"(addr));
#elif defined(CONFIG_CPU_V7M)
asm volatile ("bkpt #0xAB" : "=r" (result) : "0"(sysnum), "r"(addr));
#else
/* Note - untested placeholder */
asm volatile ("svc #0x123456" : "=r" (result) : "0"(sysnum), "r"(addr));
#endif
return result;
}
最小的、可验证的例子:
#include <stdio.h>
#include <stdlib.h>
int main(void)
{
register long result asm("r0");
void *addr = 0;
unsigned int sysnum = 0;
__asm__ volatile ("bkpt #0xAB" : "=r" (result) : "0"(sysnum), "r"(addr));
return EXIT_SUCCESS;
}
根据ARM Architecture Reference Manual bkpt
指令
采用单个 imm 参数,根据我对 GCC manual
section on inline assembly 的阅读,GCC 不允许提供操作数,如果它们
模板中未指定。使用 -S
生成的输出程序集:
.arch armv6
.eabi_attribute 28, 1
.eabi_attribute 20, 1
.eabi_attribute 21, 1
.eabi_attribute 23, 3
.eabi_attribute 24, 1
.eabi_attribute 25, 1
.eabi_attribute 26, 2
.eabi_attribute 30, 6
.eabi_attribute 34, 1
.eabi_attribute 18, 4
.file "bkpt-so.c"
.text
.align 2
.global main
.arch armv6
.syntax unified
.arm
.fpu vfp
.type main, %function
main:
@ args = 0, pretend = 0, frame = 8
@ frame_needed = 1, uses_anonymous_args = 0
@ link register save eliminated.
str fp, [sp, #-4]!
add fp, sp, #0
sub sp, sp, #12
mov r3, #0
str r3, [fp, #-8]
mov r3, #0
str r3, [fp, #-12]
ldr r2, [fp, #-12]
ldr r3, [fp, #-8]
mov r0, r2
.syntax divided
@ 10 "bkpt-so.c" 1
bkpt #0xAB
@ 0 "" 2
.arm
.syntax unified
mov r3, #0
mov r0, r3
add sp, fp, #0
@ sp needed
ldr fp, [sp], #4
bx lr
.size main, .-main
.ident "GCC: (Raspbian 8.3.0-6+rpi1) 8.3.0"
.section .note.GNU-stack,"",%progbits
那么 "=r"(result) : "0"(sysnum), "r"(addr)
在这一行中有什么意义:
__asm__ volatile ("bkpt #0xAB" : "=r" (result) : "0"(sysnum), "r"(addr));
?
最佳答案
尽管此代码存在于像 U-BOOT 这样的知名项目中,但这并不能让人放心。该代码依赖于这样一个事实,即在 ARM 架构中,ABI (call standard) 在 r0
(参数 1)、r1
(参数 2)、r2
(参数 3)和 r3
(参数 4)。
表 6.1 总结了 ABI:
U-BOOT 代码所做的假设是,当生成内联汇编时,传递给 r1
中的函数的 addr
仍然是相同的值。我认为这很危险,因为即使使用简单的非内联函数,GCC 也不能保证这种行为。我的观点是这段代码很脆弱,虽然它可能从未出现过问题,但理论上它可以。依赖底层编译器代码生成行为不是一个好主意。
我相信这样写会更好:
static noinline long smh_trap(unsigned int sysnum, void *addr)
{
register long result asm("r0");
register void *reg_r1 asm("r1") = addr;
#if defined(CONFIG_ARM64)
asm volatile ("hlt #0xf000" : "=r" (result) : "0"(sysnum), "r"(reg_r1) : "memory");
#elif defined(CONFIG_CPU_V7M)
asm volatile ("bkpt #0xAB" : "=r" (result) : "0"(sysnum), "r"(reg_r1) : "memory");
#else
/* Note - untested placeholder */
asm volatile ("svc #0x123456" : "=r" (result) : "0"(sysnum), "r"(reg_r1) : "memory");
#endif
return result;
}
此代码通过变量 (reg_r1
) 传递 addr
,该变量将被放入寄存器 r1
以实现内联汇编约束。在更高的优化级别上,编译器不会使用额外变量生成任何额外代码。我还放置了一个 memory
破坏器,因为在没有寄存器的情况下以这种方式通过寄存器传递内存地址不是一个好主意。如果有人要制作此功能的内联版本,这会带来问题。内存破坏器将确保在运行内联汇编之前将任何数据实现到内存中,并在必要时在必要时重新加载。
关于 "=r"(result) : "0"(sysnum), "r"(addr)
does 的问题是:
"=r"(result)
是一个输出约束,它告诉编译器内联汇编完成后寄存器r0
中的值将被放入变量地址
"0"(sysnum)
是一个输入约束,它告诉编译器sysnum
将通过与约束 0 相同的寄存器(constraint 0正在使用寄存器r0
)。"r"(addr)
通过寄存器传递addr
并且假设它将在r1
中与 U-BOOT代码。在我的版本中,它是这样明确定义的。
有关扩展内联汇编的操作数和约束的信息可以在 GCC documentation 中找到。您可以找到其他特定于机器的约束 here 。
hlt
、bkpt
和 svc
都被用作系统调用以通过调试器 (semihosting) 执行系统服务。您可以在半主机 here 上找到更多文档。不同的 ARM 体系结构使用略有不同的机制。半主机系统调用的约定是 r0
包含系统调用号; r1
包含系统调用的第一个参数;系统调用在返回用户代码之前在 r0
中放置一个返回值。
关于assembly - 如果没有在 ASM 模板中指定,那么提供输入和输出操作数有什么意义呢?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/62155236/