创建仓库

2025-12-11 07:24:36 +08:00
commit 0d81c1792d
128 changed files with 15104 additions and 0 deletions
--- a/系统基座文件/1/1.2/1.2.1
+++ b/系统基座文件/1/1.2/1.2.1
@@ -0,0 +1,87 @@
+---
+tags: []
+date created: 星期三, 十一月 19日 2025, 4:34:58 下午
+date modified: 星期三, 十一月 19日 2025, 4:49:09 下午
+---
+
+# 1.2.1 Host 端编译器规范 (Host Compiler Spec)
+
+**1. Host 编译器身份确证 (Host Compiler Identity)**
+
+  - **关键性**：**P0**
+  - **信息解析**：
+      - **绝对路径**：`/usr/bin/g++`。
+      - **版本指纹**：**GCC 7.3.0 (aarch64)**。
+      - **深度解读**：此版本与前序审计（1.1.1）中内核构建所用的编译器完全一致。这意味着用户态程序（Host Code）与内核态驱动（Kernel Module）拥有相同的 ABI（二进制接口）边界，极大降低了 `insmod` 时的版本冲突风险。
+  - **探测命令与结果**：
+
+    ```bash
+    /usr/bin/g++ --version
+    g++ (GCC) 7.3.0
+    Copyright (C) 2017 Free Software Foundation, Inc.
+    ```
+
+    ```bash
+    ls -l /usr/bin/g++
+    -rwxr-xr-x 4 root root 988400  2月 21  2022 /usr/bin/g++
+    ```
+
+**2. 默认语言标准支持 (Default C++ Standard)**
+
+  - **关键性**：**P1**
+  - **信息解析**：
+      - **宏定义值**：`201402L`。
+      - **标准映射**：对应 **C++14** (GNU++14)。
+      - **工程约束**：当前环境默认支持 C++14 特性（如 `std::make_unique`, `lambda capture`）。若项目代码依赖 C++17（如 `std::filesystem`, `std::optional`），必须在 `CMakeLists.txt` 中显式配置 `set(CMAKE_CXX_STANDARD 17)`，否则将导致编译失败。
+  - **探测命令与结果**：
+
+    ```bash
+    /usr/bin/g++ -dM -E -x c++ /dev/null | grep __cplusplus
+    #define __cplusplus 201402L
+    ```
+
+**3. Device 编译器与工具链锚定 (Device Compiler & Toolchain Binding)**
+
+  - **关键性**：**P0**
+  - **信息解析**：
+      - **编译器版本**：**Clang 18.1.8** (CoreX 4.3.8 Build)。这是一个非常新的版本，对现代 C++ 语法支持极佳。
+      - **工具链锚定 (Crucial)**：`Selected GCC installation: /usr/lib/gcc/aarch64-linux-gnu/7.3.0`。
+      - **深度解读**：这是异构编译中最关键的“握手”。Clang 本身不带标准库（libstdc++），它必须“借用”系统 GCC 的库。此处显示 Clang 已正确探测并绑定到了系统 GCC 7.3.0。若此处显示 `None` 或错误路径，链接阶段将必现 `undefined reference to std::…` 错误。
+  - **探测命令与结果**：
+
+    ```bash
+    which clang++
+    /usr/local/corex-4.3.8/bin/clang++
+    ```
+
+    ```bash
+    clang++ -v 2>&1 | grep "Selected GCC installation"
+    Selected GCC installation: /usr/lib/gcc/aarch64-linux-gnu/7.3.0
+    ```
+
+**4. 构建系统缓存状态 (Build System Cache State)**
+
+  - **关键性**：**P1**
+  - **信息解析**：
+      - **编译器锁定**：`CMAKE_CXX_COMPILER` 明确被锁定为 `/usr/bin/g++`，未被环境变量（如 `CC`/`CXX`）篡改为其他版本。
+      - **发布模式优化**：`CMAKE_CXX_FLAGS_RELEASE` 设为 `-O3 -DNDEBUG`。对于雷达信号处理这类计算密集型任务，`-O3` 开启了循环向量化（Loop Vectorization），这对 ARM64 NEON 指令集优化至关重要。
+  - **探测命令与结果**：
+
+    ```bash
+    grep -E "CMAKE_CXX_COMPILER|CMAKE_CXX_FLAGS" …/build/CMakeCache.txt
+    CMAKE_CXX_COMPILER:STRING=/usr/bin/g++
+    CMAKE_CXX_FLAGS_RELEASE:STRING=-O3 -DNDEBUG
+    ```
+
+**5. 产物真实性审计 (Artifact Verification)**
+
+  - **关键性**：**P2**
+  - **信息解析**：
+      - **二进制指纹**：`.o` 文件的 `.comment` 段中包含 `GCC: (GNU) 7.3.0`。
+      - **结论**：这证实了最终生成的机器码确实是由 GCC 7.3 编译的，排除了 CMake 只是“看起来”配置了 g++ 但实际调用了其他编译器的可能性（这种情况在存在 `ccache` 或 `distcc` 时偶有发生）。
+  - **探测命令与结果**：
+
+    ```bash
+    find … -name "*.o" … | grep "GCC: ("
+    GCC: (GNU) 7.3.0
+    ```
--- a/系统基座文件/1/1.2/1.2.2
+++ b/系统基座文件/1/1.2/1.2.2
@@ -0,0 +1,68 @@
+---
+tags: []
+date created: 星期三, 十一月 19日 2025, 4:54:50 下午
+date modified: 星期三, 十一月 19日 2025, 5:09:06 下午
+---
+
+# 1.2.2 Device 端编译器规范 (Device Compiler Spec)
+
+**1. Device 编译器身份与警告 (Compiler Identity & Warnings)**
+
+  - **关键性**：**P0**
+  - **信息解析**：
+      - **编译器内核**：**Clang 18.1.8** (基于 LLVM 18)。这是一个非常激进的新版本，支持最新的 C++ 标准。
+      - **关键迁移警告**：
+
+        > `clang++: warning: When compiling *.cu file for ivcore '-x cuda' need replace with '-x ivcore' …`
+
+          - **含义**：目前的构建方式使用了 `-x cuda` 标志，天数智芯编译器对此发出了**废弃警告**。
+          - **行动项**：工程文件中应尽快将编译语言标志从 `-x cuda` 迁移为 `-x ivcore`，以防未来 SDK 更新导致构建中断。
+          - **强制约束**: AI 生成的 CMakeLists.txt 中，所有 .cu 文件的编译命令必须使用 -x ivcore，严禁使用 -x cuda。
+  - **探测命令与结果**：
+
+    ```bash
+    /usr/local/corex-4.3.8/bin/clang++ --version
+    clang version 18.1.8 (4.3.8 …)
+    ```
+
+**2. 运行时库映射 (Runtime Library Mapping)**
+
+  - **关键性**：**P0**
+  - **信息解析**：
+      - **库文件位置**：`/usr/local/corex/lib` (注意不是 `lib64`)。
+      - **CUDA 兼容层 (Shim Layers)**：
+          - `libcudart.so` -\> `libcudart.so.89`：存在。这是运行时 API 的入口。
+          - `libcuda.so`：存在。这是驱动层 API 的入口。
+          - `libcufft.so`, `libcublas.so`, `libcudnn.so`：全套数学库均已存在同名替换文件。
+      - **智铠原生层 (Native Layers)**：
+          - `libixthunk.so`：推测为内核态 Thunking 层，负责最终的 syscall 下发。
+          - `libixcore.so` (via `libcv_ixcore`): 核心计算库。
+      - **链接器支持**：发现了 `LLVMgold.so`，表明该环境支持 LTO (Link Time Optimization) 链接时优化。
+  - **文件系统证据**：
+
+    ```text
+    /usr/local/corex/lib/libcudart.so -> libcudart.so.89
+    /usr/local/corex/lib/libcuda.so
+    /usr/local/corex/lib/libixthunk.so
+    ```
+
+**3. 宏定义环境 (Macro Environment)**
+
+  - **关键性**：**P1**
+  - **信息解析**：
+      - **平台标识**：`__ILUVATAR__ = 1`。代码中可以用 `#ifdef __ILUVATAR__` 编写专用优化。
+      - **兼容性标识**：`__CUDA__ = 1`，`__CUDACC__` 已定义。这是为了欺骗现有的 CUDA 代码，使其认为自己正在被 NVCC 编译。
+  - **探测命令与结果**：
+
+    ```bash
+    clang++ -dM -E -x cuda /dev/null | grep "__ILUVATAR__"
+    #define __ILUVATAR__ 1
+    ```
+
+**4. 头文件搜索优先级 (Header Search Priority)**
+
+  - **关键性**：**P0**
+  - **信息解析**：
+      - **劫持机制**：编译器优先搜索 `/usr/local/corex-4.3.8/lib/clang/18/include/cuda_wrappers`。
+      - **原理**：CoreX 在此目录下放置了与 CUDA 同名的头文件（如 `cuda_runtime.h`），拦截标准调用并映射到底层 Iluvatar Runtime。
+      - **GCC 绑定**：后续搜索路径正确回落到 Host 端的 `/usr/lib/gcc/aarch64-linux-gnu/7.3.0/`，保证了与 Host 代码的 ABI 兼容。
--- a/系统基座文件/1/1.2/1.2.3
+++ b/系统基座文件/1/1.2/1.2.3
@@ -0,0 +1,63 @@
+---
+tags: 
+date created: 星期三, 十一月 19日 2025, 5:03:58 下午
+date modified: 星期三, 十一月 19日 2025, 5:04:15 下午
+---
+
+# 1.2.3 链接器与加载器配置 (Linker & Loader)
+
+**1. 链接器身份与版本 (Linker Identity)**
+
+  - **关键性**：**P1**
+  - **信息解析**：
+      - **组件版本**：**GNU ld (Binutils) 2.34**。这是一个相对较新的版本，完全支持 AArch64 的各种重定位类型（Relocation Types）和 LTO 插件。
+      - **兼容性**：与 GCC 7.3 和 Clang 18 均能良好配合。
+  - **探测命令与结果**：
+
+    ```bash
+    ld --version
+    GNU ld (GNU Binutils) 2.34
+    ```
+
+**2. 二进制依赖解析 (Binary Dependency Analysis)**
+
+  - **关键性**：**P0**
+  - **信息解析**：
+      - **直接依赖 (NEEDED)**：`libcudart.so.2`。
+          - **深度解读**：这非常有意思。编译器（Clang）在编译时似乎模仿了 CUDA 10.2 的 ABI 行为，或者链接了伪装成 10.2 版本的存根库。这是为了让旧的 CUDA 代码无缝迁移。
+      - **运行时路径 (RPATH)**：`/usr/local/corex/lib`。
+          - **评价**：**优秀配置**。CMake 构建脚本通过 `CMAKE_INSTALL_RPATH` 或自动计算，将 SDK 库路径硬编码到了 ELF 文件头中。这是避免“DLL 地狱”的最佳实践。
+  - **探测命令与结果**：
+
+    ```bash
+    readelf -d …/bin/main_app | grep -E "RPATH|NEEDED"
+     0x0000000000000001 (NEEDED)             共享库：[libcudart.so.2]
+     0x000000000000000f (RPATH)              Library rpath: [/usr/local/corex/lib]
+    ```
+
+**3. 运行时加载器解析 (Runtime Loader Resolution)**
+
+  - **关键性**：**P0**
+  - **信息解析**：
+      - **解析结果**：`ldd` 显示 `libcudart.so.2` 被成功解析到了 `/usr/local/corex/lib/libcudart.so.2`。
+      - **结论**：运行时链接器（ld-linux）在执行程序时，优先读取了 RPATH，找到了正确的文件，而没有去系统默认目录瞎找。程序**一定**能跑起来，不会报 `cannot open shared object file`。
+  - **探测命令与结果**：
+
+    ```bash
+    ldd …/bin/main_app
+    libcudart.so.2 => /usr/local/corex/lib/libcudart.so.2 (0x0000fffeda1a0000)
+    ```
+
+**4. 系统级库路径污染 (System Library Path State)**
+
+  - **关键性**：**P2**
+  - **信息解析**：
+      - **环境变量**：`LD_LIBRARY_PATH` 被设置了多次重复的 `/usr/local/corex-4.3.8/lib`。
+          - **风险**：虽然 RPATH 优先级高于 `LD_LIBRARY_PATH`，但这种冗余设置可能在调试（Debug）或运行其他未设置 RPATH 的工具时引发困惑。建议在 `.bashrc` 中清理去重。
+      - **ld.so.conf**：系统中没有专门针对 corex 的 `.conf` 文件。这进一步凸显了 CMake 中设置 RPATH 的重要性——如果 CMake 没设 RPATH，程序必挂。
+  - **探测命令与结果**：
+
+    ```bash
+    echo $LD_LIBRARY_PATH
+    /usr/local/corex-4.3.8/lib:/usr/local/corex-4.3.8/lib:… (重复)
+    ```
--- a/系统基座文件/1/1.2/1.2.4
+++ b/系统基座文件/1/1.2/1.2.4
@@ -0,0 +1,45 @@
+# 1.2.4 混合编译兼容性 (Hybrid Compilation Compatibility)
+
+**1. C++ 标准库 ABI 兼容性 (StdLib ABI Compatibility)**
+
+  - **关键性**：**P0** (Showstopper)
+  - **信息解析**：
+      - **GCC 状态**：`#define _GLIBCXX_USE_CXX11_ABI 1`
+      - **Clang 状态**：`#define _GLIBCXX_USE_CXX11_ABI 1`
+      - **深度解读**：这是混合编译成败的关键。GCC 5.1 引入了新版 `std::string` 和 `std::list` 实现（符合 C++11 标准），并使用 Dual ABI 机制。如果两个编译器此宏定义不一致（例如一个为 0 一个为 1），链接器将无法匹配标准库符号。
+      - **结论**：两者完全对齐，**无需**在 CMake 中手动添加 `-D_GLIBCXX_USE_CXX11_ABI=0`。
+  - **探测命令与结果**：
+    ```bash
+    echo "#include <string>" | g++ … | grep ABI
+    #define _GLIBCXX_USE_CXX11_ABI 1
+    echo "#include <string>" | clang++ … | grep ABI
+    #define _GLIBCXX_USE_CXX11_ABI 1
+    ```
+
+**2. 目标架构与指令集基线 (Target Architecture Baseline)**
+
+  - **关键性**：**P1**
+  - **信息解析**：
+      - **宏定义检查**：两者均定义了 `__aarch64__` 和 `__ARM_ARCH 8`，且**均未定义** `__ARM_FEATURE_ATOMICS`。
+      - **原子指令策略**：
+          * 现代 ARMv8.1+ 引入了 LSE (Large System Extensions) 原子指令（如 `ldadd`, `cas`），性能远超传统的 LL/SC (Load-Link/Store-Conditional, 即 `ldxr/stxr`) 循环。
+          * 由于宏缺失且 grep `ldadd` 无输出，说明两个编译器都**回退到了保守的 LL/SC 模式**。
+      - **风险评估**：考虑到飞腾 S5000C 基于 ARMv8 架构，这种保守策略是**最安全**的。强制开启 LSE (`-march=armv8.1-a+lse`) 虽然可能提升原子计数器性能，但在旧微架构上会导致 `SIGILL` (非法指令崩溃)。
+  - **探测命令与结果**：
+    ```bash
+    g++ … | grep __ARM_FEATURE_ATOMICS
+    (空) -> 未启用 LSE
+    clang++ … | grep __ARM_FEATURE_ATOMICS
+    (空) -> 未启用 LSE
+    ```
+
+**3. 编译标志警告 (Compiler Flags Warning)**
+
+  - **关键性**：**P2**
+  - **信息解析**：
+      - **重复警告**：Clang 再次提示 `'-x cuda' will not be supported`。
+      - **行动项**：在 **1.2.2** 中已记录，需在 `CMakeLists.txt` 中修正语言标志。
+  - **探测命令与结果**：
+    ```text
+    clang++: warning: … need replace with '-x ivcore' …
+    ```