树莓派3 RT补丁内核自定义系统调用无法传递64位参数问询

让我来帮你拆解这个问题——我之前在ARM架构下搞自定义系统调用时也踩过类似的坑，尤其是树莓派3这种ARMv8硬件跑32位RT内核的场景，这里的核心差异确实出在系统调用的参数传递规则和用户态常规运算完全不同，下面给你分析几个关键原因和排查方向：

1. 32位ARM系统调用的参数传递限制 #

树莓派3如果跑的是32位内核（大部分RT补丁是基于32位树莓派内核做的），系统调用的参数是通过r0-r6这几个32位寄存器传递的——每个寄存器只能存32位数据。而用户态的64位数学运算，编译器会自动帮你把long long这类64位值拆成对的寄存器或者放到栈上处理，所以你感觉不到限制；但系统调用是直接走内核入口的硬逻辑，不会自动帮你拆分64位参数，如果你直接传一个64位值，内核只能拿到低32位，高32位要么丢失要么被后面的参数覆盖，自然会出现异常。

2. 内核侧系统调用的参数处理是否适配 #

你在内核里写的自定义系统调用函数，参数类型是怎么声明的？如果直接用uint64_t作为参数，在32位内核里是没办法直接通过寄存器接收的——你需要把64位参数拆成两个32位的参数来接收，比如：

asmlinkage long my_custom_syscall(uint32_t val_low, uint32_t val_high) {
    uint64_t full_val = ((uint64_t)val_high << 32) | val_low;
    // 你的业务逻辑
    return 0;
}

同时要确保系统调用表的注册和函数声明完全匹配，不然参数错位会直接导致内核崩溃或者异常。

3. 用户态syscall()的调用姿势错误 #

用户态的syscall()函数是可变参数接口，在32位ARM环境下，每个参数都会被当成32位值压入寄存器/栈。如果你直接传一个long long类型的64位值，编译器会把它拆成两个32位值，但syscall()的参数列表不会自动识别这是一个完整的64位值，会把它们当成两个独立的参数，导致内核接收到的参数顺序完全混乱。

正确的做法是手动拆分64位值，分别传递低32位和高32位：

#include <unistd.h>
#include <sys/syscall.h>
#include <stdint.h>

int main() {
    uint64_t test_val = 0x12345678abcdef00;
    // 拆分成两个32位参数传递
    syscall(397, (uint32_t)(test_val & 0xFFFFFFFF), (uint32_t)(test_val >> 32));
    return 0;
}

4. RT补丁可能带来的参数传递变化 #

虽然RT补丁主要是优化实时性（比如调度、中断响应），但有些补丁会修改系统调用的入口逻辑或者pt_regs结构体的寄存器保存方式。你可以检查一下RT补丁中有没有涉及ARM系统调用参数处理的修改，比如是否改变了寄存器的保存顺序，导致高32位参数没有被正确传递到内核函数中。

排查建议 #

• 先在内核的自定义系统调用里加printk，打印接收到的两个32位参数值，确认是不是低32位正确、高32位异常；
• 确认你的内核是32位还是64位：如果是64位内核，参数传递用的是64位寄存器，那问题可能出在系统调用号注册或者用户态syscall()的参数类型匹配上；
• 检查系统调用表的定义，确保你的系统调用对应的函数参数个数、类型和用户态传递的完全一致。

内容的提问来源于stack exchange，提问作者David Norwood