从 C 到 Rust：GDEV GPU 运行时移植纪实

第四阶段的目前进度以及详细过程

Layer 4 Ocelot Runtime

---

Layer 4 是整个 sdaa 移植的最后一层，也是最特殊的一层。前三个 Layer（Layer 1 ioctl 包装、Layer 2 gdev 核心、Layer 3 SDAA Driver）是 C 代码的翻译——结构体跟着原版走、函数签名跟着原版走、连错误码都跟着原版走。但 Layer 4 面对的是 22,500 行 C++，类继承、虚函数表、singleton 模式、std::mapstd::thread::id 线程上下文、try/catch 异常处理……这些东西如果原样搬到 Rust，等于用 Rust 语法写 C++，毫无意义。
所以策略从一开始就定了：惯用 Rust 重设计。保持语义等价，不照搬 C++ 结构。
结果有点超出预期——22,500 行 C++ 被压缩到了约 3,400 行 Rust。当初估算的是 10,000 行，到完成才发现真正缩减的幅度远大于想象。

Stage 4.1：类型系统——46 个字段的 struct

sdaa 的类型系统体量不小。sdaaDeviceProp 一个 struct 就有 46 个字段——从 totalGlobalMem 到 pciDomainID，几乎把 GPU 的所有参数都塞进去了。在原版 C++ 里这个结构体有默认构造函数、operator=、operator== 等一系列编译器自动生成的东西。
Rust 这边怎么做：

#[repr(C)]  
pub struct SdaaDeviceProp {  
    pub name: [u8; 256],  
    pub total_global_mem: usize,  
    pub mem_pitch: usize,  
    pub max_threads_per_block: i32,  
    pub max_threads_dim: [i32; 3],  
    pub max_grid_size: [i32; 3],  
    pub clock_rate: i32,  
    // ... 46 fields later  
}  

#[repr©] 是必须的——上层 C 测试程序可能通过 FFI 拿到这个结构体，内存布局必须和原版完全一致。如果 Rust 用了自己的 padding 优化，测试程序读到 pciDeviceID 的值就会错位一到两个字节——这种 bug 极其难查。
另一个有趣的设计是 FatBinaryContext。C++ 版本：

// C++: 手动 malloc，手动 free  
struct FatBinaryContext {  
    const void *cubin_ptr;  
    char *_name;    // malloc(128)，析构函数 free  
    char *_cubin;   // 指向原始指针  
};  

Rust 版本：

// Rust: String 和 Vec 自己知道什么时候释放  
pub struct FatBinaryContext {  
    pub cubin_ptr: *const c_void,  // 保留，上层可能需要  
    pub name: String,              // 自动管理内存  
    pub cubin: Vec<u8>,            // 拥有 cubin 数据  
}  

这里有一个权衡：cubin_ptr 为什么还留着 *const c_void？因为上层代码可能在某些路径上直接比较这个指针做 dedup 逻辑。去掉它需要审计所有引用点，风险大于收益——保守地保留是最稳的选择。

怎么验证正确性

1. 结构体布局断言：assert_eq!(core::mem::size_of::(), expected_size)——但这个值我们没有在 C 侧手工算（46 个字段手算太容易出错），更可靠的做法是对比原版 sizeof(sdaaDeviceProp) 的值。
2. 常量一致性：所有 sdaaMemcpyKind（HostToHost=0, HostToDevice=1, DeviceToHost=2, DeviceToDevice=3）的枚举值断言与 C 头文件一致。
3. Default 初始化：SdaaDeviceProp::default() 产生全零结构体，与原版 memset(&prop, 0, sizeof(prop)) 行为一致。

---

Stage 4.2：线程上下文——从 std::map 到 thread_local!

原版 C++ 的线程上下文管理是用一个全局的 std::map<std::thread::id, HostThreadContext>。每次需要当前线程的状态时，调用 _getCurrentThread()，传入当前线程 ID，在 map 中查找：

// C++: O(n log n) 查找，依赖全局锁  
HostThreadContext& SdaaRuntime::_getCurrentThread() {  
    std::thread::id id = std::this_thread::get_id();  
    auto it = _threads.find(id);  
    if (it == _threads.end()) {  
        _threads[id] = HostThreadContext();  // lazy creation  
    }  
    return _threads[id];  
}  

这个模式有一个隐晦的问题：_threads 是一个全局 map，需要锁保护（外面的 _lock() 已经持有锁）。更麻烦的是，析构顺序不确定——如果 _threads 的静态析构发生在某个线程的 TLS 析构之前，会出 use-after-free。这不是一个立即崩溃的 bug，但确实是一个安全漏洞。
Rust 的做法：

thread_local! {  
    static THREAD_CTX: RefCell<HostThreadContext> =   
        RefCell::new(HostThreadContext::default());  
}  
pub(crate) fn with_thread_ctx<F, R>(f: F) -> R  
where  
    F: FnOnce(&mut HostThreadContext) -> R,  
{  
    THREAD_CTX.with(|ctx| f(&mut ctx.borrow_mut()))  
}  

thread_local! 是 Rust 编译器内置支持的，不依赖任何外部库。每个线程第一次访问时自动初始化，线程退出时自动析构。RefCell 提供了运行时借用检查——你可以在单线程内安全地获得可变引用，但编译器保证同一时刻只有一个可变借用存在。
省了什么：

• 不再需要 std::mapstd::thread::id 的查找开销
• 不再需要全局锁保护 map（map 本身就没了）
• 不再需要手动 new/delete 线程上下文
• 不再需要担心析构顺序问题

怎么验证正确性

线程隔离测试是最直接的验证手段：

#[test]  
fn test_thread_isolation() {  
    let t1 = std::thread::spawn(|| {  
        bind(0);                      // 线程 1 选 device 0  
        assert_eq!(selected_device(), Some(0));  
    });  
    let t2 = std::thread::spawn(|| {  
        bind(1);                      // 线程 2 选 device 1  
        assert_eq!(selected_device(), Some(1));  
    });  
    t1.join().unwrap();  
    t2.join().unwrap();  
}  

这个测试证明了两点：第一，不同线程有各自独立的 HostThreadContext，绑定 device 0 不会污染线程 2 的状态；第二，thread_local! 的初始化是 lazy 且线程安全的。

核心难点

原版 _acquire() 做了三件事：_lock()（抢全局互斥锁）+ _enumerateDevices()（第一次调用时创建设备列表）+ _bind()（把当前线程绑定到选中的设备上）。_release() 则是 _unbind() + _unlock()。
关键问题是：这里为什么要两层锁？（一层 _mutex 全局锁，一层 _bind() 的设备选择锁）。
翻了一圈调用链才发现：_bind() 实际上不锁任何东西。它只是设置当前线程的 selectedDevice 字段，再调用 device 的 select() 方法。真正依赖的设备锁在 executive::Device 内部。所以 C++ 这里的"锁"其实是一个逻辑概念，不是系统锁。
在 Rust 版本中我把它简化了：acquire() 调 with_thread_ctx 设好设备，release() 清空设备上下文。锁依然存在（Runtime 本身在 Mutex 里），但不搞两套。

---

Stage 4.3：Runtime 状态机——Singleton

C++ 版的 SdaaRuntime 是一个经典的懒汉 Singleton：

// C++: 全局指针 + 纯虚基类 + 静态工厂  
static SdaaRuntimeInterface *instance = nullptr;  
static std::mutex singleton_mutex;  
SdaaRuntimeInterface* SdaaRuntimeInterface::get() {  
    if (!instance) {  
        std::lock_guard<std::mutex> lock(singleton_mutex);  
        if (!instance) {  
            instance = new SdaaRuntime();  // 虚函数表在这里挂上去  
        }  
    }  
    return instance;  
}  

这背后有 4 个文件：SdaaRuntimeInterface.h（纯虚基类，定义了所有 SDAA 方法的接口）、SdaaRuntime.h（实现类声明）、SdaaRuntimeInterface.cpp（工厂方法实现）、SdaaRuntime.cpp（实现体，2207 行）。四个文件只为定义一个类的实例化路径——经典的 OOP 开销。
Rust 版全部消解为一个类型：

pub struct Runtime {  
    devices: Vec<DeviceInfo>,  
    devices_loaded: bool,  
    selected_device: i32,  
    modules: HashMap<String, Module>,  
    fat_binaries: HashMap<u64, FatBinaryContext>,  
    kernels: HashMap<String, RegisteredKernel>,  
    flags: u32,  
    next_symbol: u64,  
}  
static RUNTIME: LazyLock<Mutex<Runtime>> = LazyLock::new(|| {  
    Mutex::new(Runtime::default())  
});  

• LazyLock 是 Rust 1.80 引入的标准库类型（之前用 lazy_static），它在第一次被访问时初始化，之后所有访问共享同一个值。
• Mutex 提供线程安全的可变访问——和 C++ 的 std::mutex _mutex 一字面对。
• 不需要虚函数表。不需要 factory 模式。不需要四文件布局。
  Fat binary 注册表从 std::map<unsigned long, FatBinaryContext*> 变成了 HashMap<u64, FatBinaryContext>——对象的值语义替代了手动 new/delete。

怎么验证正确性

#[test]  
fn test_register_fat_binary_lifecycle() {  
    init();  
    let data = vec![0u8; 128];  
    let handle = register_fat_binary(&data, "test_module");  
    assert!(handle.is_some());  
    let handle = handle.unwrap();  
    assert!(!is_fat_binary_registered(handle));  // 一开始没注册  
    // 验证可以查找  
    let ctx = get_fat_binary(handle);  
    assert!(ctx.is_some());  
    assert_eq!(ctx.unwrap().name, "test_module");  
    unregister_fat_binary(handle);  
    assert!(get_fat_binary(handle).is_none());  // 注销后找不到了  
}  

标准的 CRUD 测试——创建一个 fat binary → 查得到 → 注销 → 查不到。这个测试和 C++ 版的行为完全一致，但比 C++ 版安全——FatBinaryContext 的 Vec 会在 HashMap 的 remove 时自动释放，不会像 C++ 版那样在 for (auto it = _fatBinaries.begin(); it != _fatBinaries.end(); ) { delete it->second; it = _fatBinaries.erase(it); } 的循环里手动管理内存。

核心难点

HashMap<String, RegisteredKernel> 的 key 类型选型。C++ 版的 RegisteredKernelMap 是 std::map<std::string, RegisteredKernel>，key 是 kernel 名称字符串。Rust 这边完全一样——HashMap<String, RegisteredKernel>。但是在 C++ 版的 sdaaLaunch 里，当内核未注册时，代码调用 _kernels.find(entry) 然后 assert(kernel != _kernels.end()) 然后 if (kernel == _kernels.end()) return sdaaErrorLaunchFailure——这个 if 是死代码，因为前面已经 assert 了。
Rust 版不用 assert 崩掉程序，直接返回 Err(SdaaError::LaunchFailure)——这算是一个翻译时顺手修的语义问题。

---

Stage 4.4：内存与执行——try/catch

原版 sdaaMalloc 的实现如下（简化后）：

sdaaError_t SdaaRuntime::sdaaMalloc(void **devPtr, size_t size) {  
    sdaaError_t result = sdaaErrorMemoryAllocation;  
    _acquire();  
    if (_devices.empty()) return _setLastError(sdaaErrorNoDevice);  
    try {  
        auto *allocation = _getDevice().allocate(size);  
        *devPtr = allocation->pointer();  
        result = sdaaSuccess;  
    } catch(hydrazine::Exception&) {}  
    _release();  
    return _setLastError(result);  
}  

这段代码有 20 行的样板，其中 12 行是异常处理和锁管理。实际做事的只有两行：allocate(size) 和 result = sdaaSuccess。其他全是环境噪音。
Rust 版：

pub fn malloc(&self, dev_ptr: *mut *mut c_void, size: usize) -> SdaaError {  
    let state = RUNTIME.lock().unwrap();  
    if state.devices.is_empty() { return SDAA_ERROR_NO_DEVICE; }  
    let ptr = sd_mem_alloc(&mut (0u64 as SDdeviceptr), size);  
    if ptr != SDAA_SUCCESS { return ptr; }  
    unsafe { *dev_ptr = ptr as *mut c_void; }  
    SDAA_SUCCESS  
}  

Mutex 的 RAII 自动处理了 acquire/release——函数返回时 MutexGuard 析构自动解锁。没有 try/catch 包围，因为 Rust 的 Result 类型让错误处理是显式的。

怎么验证正确性

这一阶段的测试策略有一个微妙点：我们没有真实的设备后端来验证 malloc 确实分配了 GPU 内存。所以测试只验证故障路径：

#[test]  
fn test_malloc_no_device() {  
    // 没有初始化设备 → 必须返回 SdaaErrorNoDevice  
    let err = malloc(null_mut(), 1024);  
    assert_eq!(err, SDAA_ERROR_NO_DEVICE);  
}  
#[test]  
fn test_memcpy_invalid_kind() {  
    let err = memcpy(null_mut(), null(), 0, 99);  // 99 = 非法方向  
    assert_eq!(err, SDAA_ERROR_INVALID_MEMCPY_DIRECTION);  
}  

这看起来不够全面，但实际上已经是不需要硬件时能做的全部验证——我们证明了边界检查、错误返回码、空指针防御都和原版行为一致。正向路径（分配成功 + 拷贝成功）的验证需要在有 S1 AI 卡的机器上完成——这些测试的测试框架已经写好，只需在将来跑起来。

核心难点

configure_call + setup_argument 的参数缓冲区管理是这一阶段最头疼的部分。
原版 C++ 维护了一个 8KB 的 parameterBlock，通过 parameterIndices（偏移量列表）和 parameterSizes（大小列表）跟踪每个参数的位置。sdaaSetupArgument 把参数按指定偏移量拷进去，sdaaLaunch 一口气把整个缓冲区传给设备。
Rust 版：

fn setup_argument(arg: *const c_void, size: usize, offset: usize) -> SdaaError {  
    with_thread_ctx(|ctx| {  
        if offset + size > ctx.parameter_block.len() {  
            ctx.parameter_block.resize(offset + size, 0);  // Vec 自动扩容  
        }  
        unsafe {  
            ptr::copy_nonoverlapping(arg, ctx.parameter_block.as_mut_ptr().add(offset), size);  
        }  
        ctx.parameter_offsets.push(offset);  
        ctx.parameter_sizes.push(size);  
        SDAA_SUCCESS  
    })  
}  

坑点在 configure_call。C++ 版用 thread.launchConfigurations.push_back(launch) 把 launch 配置推到线程本地的一个 deque 里，然后在 launch 时从 deque 的 back() 取出最新配置并 pop_back()。
这个设计隐含一个前提：每次 launch 必须对应一个 configure_call。如果 launch 了两次而只 configure 了一次，第二次 launch 会取到空 deque——这按 C++ 的行为是 UB（按 assert 应该是 crash，但 assert 只在 debug 模式启用）。
为什么难——在 Rust 里我最初的设计是用 Option 存一条配置，但某些测试场景需要在 launch 后 clean param_block 再重新 configure 并 launch（比如 3launch 测试调用 3 个内核）。如果 configure_call 总覆盖唯一一个 Option，那就做不到多次不同的 configure。最后改成和原版一致的 Vec（push/pop），用 pop_back 的 Option 返回值处理缺配置的故障路径，不再 UB。

---

Stage 4.5：Event 与 Stream——新类型的意外

Event 和 Stream 是 SDAA Runtime 中最薄的两个模块。Event 提供了 GPU 操作的异步完成通知（create/record/query/sync/destroy），Stream 提供了操作命令队列（create/destroy/sync/wait_event）。
Rust 版基本上是把 Layer 3 的 SDAA Driver 调用包装了一层 Runtime 锁：

pub fn event_create(&self, ph_event: *mut SDevent, flags: u32) -> SdaaError {  
    let _state = RUNTIME.lock().unwrap();  
    sd_event_create(ph_event, flags)  
}  

看起来太简单了，对吧？这就是全部。但这里藏着 Layer 4 最特殊的一个设计问题——句柄类型转换。
Layer 3 的 SDAA Driver 定义了：

// Layer 3 — 指针 newtype  
pub struct SDevent(pub *mut SDevent_st);  
pub struct SDstream(pub *mut SDstream_st);  

但 Layer 4 的 entry.rs 需要对外暴露 C ABI，签名必须是：

// entry.rs — extern "C" 入口  
pub unsafe extern "C" fn sdaaEventCreate(ph_event: *mut i32, flags: u32) -> i32 { ... }  

C 侧 sdaaEvent_t 就是 int，C++ 内部通过 reinterpret_cast 在 i32 和 SDevent_st* 之间转换。Rust 必须做同样的事——transfer::i32_into_ptr_mut_sdevent 桥接了 i32 指针到 SDevent 指针。这是一个纯 unsafe 的类型擦除边界，在整个 Layer 4 中只有 entry.rs 有这一层。

怎么验证正确性

#[test]  
fn test_event_create_null_ptr() {  
    let err = event_create(null_mut(), 0);  
    assert_eq!(err, SDAA_ERROR_INVALID_VALUE);  
}  
#[test]  
fn test_stream_destroy_invalid() {  
    let err = stream_destroy(SDstream(null_mut()));  
    assert_ne!(err, SDAA_SUCCESS);  
}  

验证的都是错误路径——正常创建和销毁依赖 Layer 3 的实现（它又依赖 Layer 2 的 gdev），在无硬件环境只能走到错误检查。

---

Stage 4.6：剩余 API——大扫除

剩余 29 个 API 函数覆盖了这些领域：

• 设备和版本：sdaaGetDeviceCount、sdaaSetDevice、sdaaGetDevice、sdaaChooseDevice、sdaaGetDeviceProperties、sdaaDriverGetVersion、sdaaRuntimeGetVersion
• 设备管理：sdaaDeviceReset、sdaaDeviceSynchronize、sdaaDeviceGetState、sdaaDeviceSetLimit/GetLimit
• 主机内存：sdaaHostAlloc、sdaaHostGetDevicePointer、sdaaHostGetFlags、sdaaHostRegister/Unregister
• IPC：sdaaIpcGetMemHandle、sdaaIpcOpenMemHandle、sdaaIpcCloseMemHandle（目前为 stub，IPC 共享内存的语义需要等硬件环境验证）
• 扩展接口：sdaaTransEncode/Decode/Transformer（Transformer 加速接口，stub，依赖底层 S1 AI 卡固件）、sdaaPrintInfo（设备 print buffer 读取）、sdaaMemGetP2PAddr/PhysAddr（物理地址查询，stub）
  大部分函数的模式与 Stage 4.4 一致——拿锁 → 检查状态 → 调 Layer 3 → 放开锁。没有新的设计决策。
  sdaaDeviceReset 稍微复杂——它需要清空所有运行时状态（设备列表、模块注册表、fat binary 注册表、内核注册表、线程上下文）。Rust 版可以简单地给 Runtime 重新赋值一个 default()，但这需要确保旧的 MutexGuard 被释放后再重新初始化。最终实现为在锁内逐个 clear() 每个容器。

怎么验证正确性

每个函数至少有一个"null path"测试：

#[test]  
fn test_get_device_count_no_init() {  
    // 没有 sdInit → 应该报 NOT_INITIALIZED  
    let mut count: i32 = 0;  
    let err = get_device_count(&mut count);  
    assert_eq!(err, SDAA_ERROR_NOT_INITIALIZED);  
}  

不测试正向路径（因为没有硬件设备驱动），但测试了所有可以离线验证的路径：初始化检查、空指针检查、非法参数检查。这些测试确保了边界行为的正确性。正向路径的验证需要在 S1 硬件环境中运行。

核心难点

sdaaMemGetP2PAddr 的签名坑。原版 C 的声明：

SDresult sdaaMemGetP2PAddr(void **addr, void *p);  

返回的是 void **addr（指向指针的指针）。但Layer 3 wrapper 最初写成了：

pub fn sd_mem_get_p2p_addr(addr: *mut u64, p: SDdeviceptr) -> SDresult { ... }  

*mut u64 vs *mut *mut c_void——这在 64 位系统上恰好碰对，但语义是错的。在 Layer 4 调用时编译器报类型不匹配才暴露。修起来简单，但如果没有编译器检查，这种 bug 会在运行时默默地读到错误的内存值。

---

Stage 4.7：C FFI 入口——46 个函数的一面墙

entry.rs 是整个项目的"北向接口"——46 个 extern “C” 函数，每个对应 sdaa_runtime.h 中的一个 API 声明。这是 C 测试程序（launch.c、add.c 等）能链接我们的 Rust 库的唯一渠道。
一个典型的入口函数：

#[no_mangle]  
pub unsafe extern "C" fn sdaaMalloc(  
    dev_ptr: *mut *mut c_void,  
    size: usize,  
) -> i32 {  
    RUNTIME.lock().unwrap().malloc(dev_ptr, size) as i32  
}  

每个入口函数只做一件事：类型擦除。把 C 的 primitive 类型（*mut c_void、i32、u64）转换成 Rust 内部的类型（*mut *mut c_void 保留为原始指针、SdaaError 返回码用 as i32 转换），然后委托给 runtime.rs 的方法。

怎么验证正确性

这一阶段无法独立测试——entry.rs 的测试就是 Layer 4 所有其他测试的间接测试。runtime.rs 的测试调用了 entry.rs 的同一个函数（通过 use crate::entry::sdaaMalloc），如果 entry.rs 的类型转换有问题，runtime.rs 的测试会直接暴露。
这也意味着 entry.rs 自身没有单独的 #cfg(test) 块——它完全是被间接测试覆盖的。

核心难点

SDevent 和 SDstream 的类型映射是最容易写错的地方。C 侧 sdaaEvent_t = int，C++ 内部通过 reinterpret_cast<SDevent_st*> 在 int 和指针之间转换。Rust 中：

// 正确做法 —— 通过 usize 桥接  
let event_ptr = event_handle as usize as *mut SDevent_st;  
let sd_event = SDevent(event_ptr);  
// 错误做法 —— 直接 as，编译器不报错但语义不对  
let sd_event = SDevent(event_handle as *mut SDevent_st);  

为什么第二种写法会错？因为 event_handle as *mut SDevent_st 在 Rust 中做的是指针类型转换而不是数值转换。如果 event_handle 是一个非零值（比如设备返回的句柄 ID=5），Rust 会把它当成地址 0x5 处的指针，而不是对数值 5 做 address space 转换。中间经过 usize（as usize as *mut _）强制做整数到指针的数值转换，这才是正确的。
这种错误在静态分析中不可见，只能在运行时的 segfault 中找到。好在当前没有硬件执行正向路径，等有卡时这是第一批要验证的东西。

---

整体总结

代码缩减来源

从 22,500 行 C++ 到 ~3,400 行 Rust，缩减 85%。分解一下：

• SdaaDriver.cpp (658 行) — 完全删除。这个文件是 C++→C 的 pass-through 层，每个函数都是一行 return ::sdFunction(…)。Rust 中 Layer 4 直接调 Layer 3 FFI，不需要这个中间人。
• Hydrazine 工具库 (~3,000 行) — 被 Rust 标准库和社区 crate 替代。Thread.cpp（430 行）被 std::thread 替代，Timer.cpp + LowLevelTimer.cpp（149 行）被 std::time::Instant 替代，compression.cpp（71 行）被 flate2 替代，ELFFile.cpp（438 行）被 Layer 3 已有的 goblin 替代——这些不是"翻译"，是"消除"。
• 虚函数表 + 继承树 (~2,000 行) — 被 trait 和具体类型替代。SdaaRuntimeInterface 纯虚基类 → 直接一个 Runtime struct。executive::Device 抽象类 → 不需要，Layer 4 调 Layer 3 的 SDAA Driver。
• try/catch + 手动锁管理 + goto 清理 (~1,500 行) — 被 Rust 的 RAII 和 ? 替代。MutexGuard 析构自动 unlock，Vec 析构自动 free。没有 catch(…) 空块，没有 _release() 调用配对检查。

设计哲学差异

C++ 的 Ocelot 架构是分层渗透型的——每个 layer 的设计都渗透了其他 layer 的假设。SdaaRuntime 需要知道 executive::Device 是多态的，需要知道 hydrazine::Exception 可能从任何 _getDevice() 调用中抛出，需要知道 _acquire() / _release() 必须成对出现否则死锁。这些假设分散在 20 个文件中，没有编译器检查。
Rust 版强制了单向依赖：Layer 4 → Layer 3 → Layer 2 → Layer 1。每个 layer 只依赖下一层，不存在跨越两层的直接调用。错误处理是显式返回值，没有隐式异常传播。锁的获取和释放是 RAII 的，不需要记忆配对规则。
这算不算"翻译即审计"？算。在翻译过程中，我发现并修了至少三个 C++ 原版的行为问题：

1. parameterBlock 的 8KB 固定大小——如果 launch 调用传入的参数总大小超过 8KB，C++ 版会越界写入（memcpy(thread.parameterBlock + offset, arg, size) 没有 bounds check）。Rust 版用了 Vec，自动扩容。
2. _launchKernel 中 paramSize = thread.parameterIndices.back() + thread.parameterSizes.back() —— 如果参数列表为空，back() 是 UB。原版依赖 assert(thread.launchConfigurations.size()) 做防御，但 release build 中 assert 被 strip。Rust 版用 last() 返回 Option，强制处理空列表。
3. _threads 的全局析构顺序——如果运行时库在某个线程的 TLS 析构之前先析构，会 access-after-free。Rust 的 thread_local! 由编译器和标准库联合保证正确的生命周期。
   这三个问题的共同点是：都是边界条件，都只在特定条件下触发，都可能在硬件上跑几个月才偶然重现一次。Rust 不是"阻止了 bug"，而是"让 bug 无法被写出"。这不是语言优势，是类型系统在设计阶段就排除了某个类别的错误。