创建仓库

2025-12-11 07:24:36 +08:00
commit 0d81c1792d
128 changed files with 15104 additions and 0 deletions
--- a/系统基座文件/1/1.4/1.4.1
+++ b/系统基座文件/1/1.4/1.4.1
@@ -0,0 +1,48 @@
+---
+tags: []
+date created: 星期三, 十一月 19日 2025, 7:24:00 晚上
+date modified: 星期三, 十一月 19日 2025, 7:27:31 晚上
+---
+
+# 1.4.1 CMake 核心环境 (CMake Core)
+
+**1. 构建工具版本 (CMake Version)**
+
+  - **关键性**：**P1**
+  - **信息解析**：
+      - **物理版本**：**4.1.2**。这是一个非常新的版本（User Context 为 2025 年 11 月），意味着它原生支持现代 C++20/23 特性及最新的构建策略。
+      - **项目约束**：`cmake_minimum_required(VERSION 3.10)`。
+      - **结论**：版本兼容性极佳。CMake 4.x 完全向后兼容 3.x 语法。
+  - **探测命令与结果**：
+
+    ```bash
+    cmake --version
+    cmake version 4.1.2
+    ```
+
+**2. 构建生成器 (Build Generator)**
+
+  - **关键性**：**P1**
+  - **信息解析**：
+      - **类型**：**Unix Makefiles**。
+      - **评价**：这是 Linux 环境下的经典默认值。
+      - **优化建议**：对于拥有 64 核以上的飞腾 S5000C 平台，若后续发现增量编译速度较慢，可考虑切换为 **Ninja** (`cmake -G Ninja …`)，其依赖分析速度通常优于 Make。目前保持 Makefiles 亦无大碍。
+  - **探测命令与结果**：
+
+    ```bash
+    grep "CMAKE_GENERATOR" …/CMakeCache.txt
+    CMAKE_GENERATOR:INTERNAL=Unix Makefiles
+    ```
+
+**3. 工具链隔离状态 (Toolchain Isolation)**
+
+  - **关键性**：**P2**
+  - **信息解析**：
+      - **状态**：`CMAKE_TOOLCHAIN_FILE` 为空。
+      - **架构意义**：这意味着 CMake 没有加载外部的交叉编译配置脚本。所有的编译器指定（Host GCC / Device Clang）均完全由项目内部的 `CMakeLists.txt` 显式控制。这符合“显式异构分离”的设计模式。
+  - **探测命令与结果**：
+
+    ```bash
+    grep "CMAKE_TOOLCHAIN_FILE" …/CMakeCache.txt
+    (Empty)
+    ```
--- a/系统基座文件/1/1.4/1.4.2
+++ b/系统基座文件/1/1.4/1.4.2
@@ -0,0 +1,55 @@
+---
+tags: 
+aliases:
+  - 1.4.2 异构编译器编排策略 (Heterogeneous Compiler Orchestration)
+date created: 星期三, 十一月 19日 2025, 7:27:38 晚上
+date modified: 星期三, 十一月 19日 2025, 7:42:22 晚上
+---
+
+# 1.4.2 异构编译器编排策略 (Heterogeneous Compiler Orchestration)
+
+**审计综述**：
+项目采用了\*\*“Host 主导，Device 旁路”\*\* 的编排模式。通过显式锁定 Host 编译器并禁用 CMake 原生 CUDA 支持，彻底规避了标准 `FindCUDA` 模块在国产异构环境下的兼容性问题。这种配置极其稳健，是当前环境下的最佳实践。
+
+**1. Host 编译器锁定 (Host Compiler Locking)**
+
+  - **关键性**：**P0**
+  - **策略解析**：
+      - **配置**：`set(CMAKE_CXX_COMPILER "/usr/bin/g++")`。
+      - **深度解读**：
+          - **绝对路径**：使用了 `/usr/bin/g++`，消除了 `cc` 或 `c++` 软链接指向不明的风险。
+          - **ABI 锚定**：强制使用系统 GCC，确保了与 OS 内核（GCC 7.3 构建）及系统库（libstdc++）的二进制兼容性。这是混合编译稳定性的基石。
+  - **探测依据**：
+
+    ```cmake
+    set(CMAKE_CXX_COMPILER "/usr/bin/g++")
+    ```
+
+**2. Device 编译器传递 (Device Compiler Passing)**
+
+  - **关键性**：**P1**
+  - **策略解析**：
+      - **配置**：`set(CLANG_CUDA_COMPILER "clang++")`。
+      - **风险提示**：当前配置使用相对命令名。在多编译器共存的环境中（如同时安装了系统 Clang），可能导致误调用。建议优化为 `${COREX_PATH}/bin/clang++` 以实现物理隔离。
+      - **角色**：此变量主要用于后续 `add_custom_command` 或自定义编译规则中，作为处理 `.cu` 文件的专用工具。
+  - **探测依据**：
+
+    ```cmake
+    set(CLANG_CUDA_COMPILER "clang++")
+    ```
+
+**3. 语言标准范围定义 (Language Scope Definition)**
+
+  - **关键性**：**P0**
+  - **策略解析**：
+      - **配置**：`project(SignalProject LANGUAGES CXX)`。
+      - **核心逻辑**：
+          - **仅启用 CXX**：明确告知 CMake 这是一个纯 C++ 项目。
+          - **禁用 CUDA**：`grep "enable_language(CUDA)"` 为空，表明未启用 CMake 的原生 CUDA 支持。
+      - **架构优势**：这避免了 CMake 试图去寻找 NVCC 或执行标准的 CUDA 设备链接（Device Linking）流程，从而让开发者完全掌控智铠 GPU 代码的编译参数（如 `-x ivcore`）。
+  - **探测依据**：
+
+    ```cmake
+    project(SignalProject LANGUAGES CXX)
+    # enable_language(CUDA) -> Not Found
+    ```
--- a/系统基座文件/1/1.4/1.4.3
+++ b/系统基座文件/1/1.4/1.4.3
@@ -0,0 +1,55 @@
+---
+tags: 
+aliases:
+  - 1.4.3 编译选项与性能开关 (Compilation Flags & Performance Switches)
+date created: 星期三, 十一月 19日 2025, 7:30:01 晚上
+date modified: 星期三, 十一月 19日 2025, 7:42:46 晚上
+---
+
+# 1.4.3 编译选项与性能开关 (Compilation Flags & Performance Switches)
+
+**审计综述**：
+当前构建系统在功能层面已适配智铠 SDK（正确使用了 `-x ivcore`），但在性能调优层面尚处于“默认状态”，缺失针对飞腾 CPU 的特定优化标志。
+
+**1. Host 端编译标志策略 (Host Compilation Strategy)**
+
+  - **关键性**：**P1**
+  - **策略解析**：
+      - **构建类型管理**：正确区分了 `Release` (`-O3 -DNDEBUG`) 和 `Debug` (`-g`) 模式。CMake 默认的 Release 配置已开启最高等级的循环向量化优化。
+      - **架构优化 (缺失)**：未检测到 `-march=armv8-a` 或 `-mtune=phytium`。
+          - **改进建议**：建议显式添加 `-march=armv8-a` 以启用 ARMv8 指令集特性。鉴于 1.2.4 审计显示编译器未启用 LSE 原子指令，暂不建议添加 `+lse`，以免引入兼容性问题。
+      - **警告等级 (缺失)**：主业务代码 (`signal_lib`) 未开启 `-Wall`，建议补全。
+  - **探测依据**：
+
+    ```bash
+    grep "CMAKE_CXX_FLAGS_RELEASE" …/CMakeCache.txt
+    CMAKE_CXX_FLAGS_RELEASE:STRING=-O3 -DNDEBUG
+    ```
+
+**2. Device 端方言与架构标志 (Device Dialect & Arch Flags)**
+
+  - **关键性**：**P0**
+  - **策略解析**：
+      - **核心方言标志**：检测到关键标志 **`-x ivcore`**。
+          - **深度解读**：这是智铠编译器（Clang-based）识别 `.cu` 文件的“暗号”。不同于 NVCC 自动处理后缀，Clang 需要显式告知语言类型。该标志的存在证明构建脚本已针对 CoreX SDK v4.x 进行了正确适配。
+      - **包含路径**：正确注入了 `-I/usr/local/corex/include`，确保 `cuda_runtime.h` 等头文件可见。
+      - **位置无关代码**：虽然未显式 grep 到 `-fPIC`，但通常 CMake 处理动态库时会自动添加。若构建静态库（当前情况），此选项非必须。
+  - **探测依据**：
+
+    ```bash
+    grep -r "clang++" …
+    /bin/clang++ -x ivcore …
+    ```
+
+**3. 宏定义管理 (Macro Management)**
+
+  - **关键性**：**P2**
+  - **策略解析**：
+      - **调试宏**：`NDEBUG` 在 Release 模式下正确定义，禁用了 `assert()` 检查，减少运行时开销。
+      - **平台宏**：未在 CMake 中显式定义 `__ILUVATAR__`。这不是问题，因为 1.2.2 审计已确认 Device 编译器会在预处理阶段自动注入该宏。
+  - **探测依据**：
+
+    ```bash
+    grep "CMAKE_CXX_FLAGS_RELEASE" …
+    … -DNDEBUG
+    ```
--- a/系统基座文件/1/1.4/1.4.4
+++ b/系统基座文件/1/1.4/1.4.4
@@ -0,0 +1,70 @@
+---
+tags: 
+aliases:
+  - 1.4.4 依赖管理与链接逻辑 (Dependency Management & Linking Logic)
+date created: 星期三, 十一月 19日 2025, 7:48:04 晚上
+date modified: 星期三, 十一月 19日 2025, 7:48:14 晚上
+---
+
+# 1.4.4 依赖管理与链接逻辑 (Dependency Management & Linking Logic)
+
+**1. 依赖获取策略 (Dependency Acquisition Strategy)**
+
+  - **关键性**：**P1**
+  - **策略解析**：
+      - **在线拉取**：使用了现代 CMake 的 `FetchContent` 模块在线管理 GoogleTest。
+      - **优势**：相比传统的 `ExternalProject_Add`，`FetchContent` 在配置阶段即下载源码，使得子项目可以直接参与主构建树的编译，非常适合 CI/CD 自动化环境。
+      - **配置状态**：已配置 `gtest_force_shared_crt` 等缓存变量，确保运行时库兼容。
+  - **探测依据**：
+
+    ```cmake
+    include(FetchContent)
+    FetchContent_Declare(…)
+    FetchContent_MakeAvailable(googletest)
+    ```
+
+**2. 头文件暴露与隔离 (Header Visibility & Isolation)**
+
+  - **关键性**：**P0**
+  - **策略解析**：
+      - **目标级管理**：全面采用 `target_include_directories`。
+      - **传递性控制**：
+          - `signal_lib` 使用了 **PUBLIC** 属性。这意味着任何链接了 `signal_lib` 的目标（如 `main_app`），都会自动继承其头文件搜索路径。这是构建库（Library）的标准范式。
+          - GTest 使用了 **SYSTEM INTERFACE**，有效屏蔽了第三方库可能产生的编译器警告。
+  - **探测依据**：
+
+    ```cmake
+    target_include_directories(signal_lib PUBLIC …)
+    ```
+
+**3. 链接传递性与作用域 (Linking Transitivity & Scope)**
+
+  - **关键性**：**P0**
+  - **策略解析**：
+      - **层级清晰**：
+          - `signal_lib` 封装了底层的 SDK 细节（链接 `cudart`），对外暴露为高级接口。
+          - `main_app` 仅需链接业务库 `signal_lib` 和系统库 `numa`，无需关心底层是否使用了 CUDA。
+      - **链接模式**：
+          - `main_app` 使用 **PRIVATE** 链接 `numa`（仅自己用，不传递）。
+          - `signal_lib` 使用 **PUBLIC** 链接 `cudart`（依赖传递）。
+  - **探测依据**：
+
+    ```cmake
+    target_link_libraries(main_app PRIVATE signal_lib numa)
+    target_link_libraries(signal_lib PUBLIC cudart)
+    ```
+
+**4. 运行时路径注入 (RPATH Mechanism)**
+
+  - **关键性**：**P0 (Critical)**
+  - **策略解析**：
+      - **物理状态**：`readelf` 确认二进制文件头部包含 `Library rpath: [/usr/local/corex/lib]`。
+      - **生成机制**：尽管源码中未显式设置 `CMAKE_INSTALL_RPATH`，但由于链接时使用了库的绝对路径（推测 `cudart` 变量解析为 `/usr/local/corex/lib/libcudart.so`），CMake 默认会将非系统路径（Non-standard Path）自动添加到 Build Tree 的 RPATH 中。
+      - **运维价值**：这确保了程序部署到生产环境时，**不需要**配置 `LD_LIBRARY_PATH` 环境变量即可运行，极大地降低了运维出错率。
+  - **探测依据**：
+
+    ```bash
+    readelf -d …/bin/main_app | grep RPATH
+    0x000000000000000f (RPATH)   Library rpath: [/usr/local/corex/lib]
+    ```
+
--- a/系统基座文件/1/1.4/1.4.5
+++ b/系统基座文件/1/1.4/1.4.5
@@ -0,0 +1,64 @@
+---
+tags: []
+date created: 星期三, 十一月 19日 2025, 7:50:36 晚上
+date modified: 星期三, 十一月 19日 2025, 7:51:09 晚上
+---
+
+# 1.4.5 产物输出与安装规则 (Artifact Output & Installation Rules)
+
+**审计综述**：
+项目采用了\*\*“集中式输出”**策略，极大地方便了开发阶段的调试与运行。然而，主构建脚本**完全缺失了安装规则 (`install`)\*\*，这意味着无法通过 `make install` 将产物打包或部署到系统目录，当前仅限于在构建目录（Build Tree）内运行。
+
+**1. 输出目录布局 (Output Directory Layout)**
+
+  - **关键性**：**P1**
+  - **策略解析**：
+      - **集中管理**：通过设置 `CMAKE_RUNTIME_OUTPUT_DIRECTORY` 等变量，强制将所有生成物归档到 `${CMAKE_BINARY_DIR}/bin` 和 `${CMAKE_BINARY_DIR}/lib`。
+      - **优势**：
+          - 避免了编译产物散落在源码目录深处（In-source build pollution）。
+          - 简化了 `RPATH` 的管理，因为所有库都在同一个相对路径下。
+          - 方便了 `numactl` 等工具的调用路径书写（如 1.3.3 中所示）。
+  - **探测依据**：
+
+    ```cmake
+    set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/bin)
+    ```
+
+**2. 安装规则状态 (Installation Rule Status)**
+
+  - **关键性**：**P2 (Missing)**
+  - **策略解析**：
+      - **现状**：`grep "install("` 显示主项目（`app` 和 `signal_lib`）**未定义任何安装规则**。仅有的安装指令来自第三方依赖（GTest）和 SDK 内部文件。
+      - **影响**：运行 `make install` 将不会复制雷达主程序或库文件。对于目前的 Demo / 原型开发阶段，这是可接受的。
+      - **改进建议**：若项目进入生产交付阶段，必须补充 `install(TARGETS main_app DESTINATION bin)` 等指令，以便生成发布包（RPM/DEB）。
+  - **探测依据**：
+
+    ```bash
+    grep -r "install(" …
+    # (无主项目相关输出)
+    ```
+
+**3. 调试符号与剥离策略 (Debug Symbol Strategy)**
+
+  - **关键性**：**P2**
+  - **策略解析**：
+      - **物理状态**：`file` 命令显示 `not stripped`，说明符号表（Symbol Table）保留，可支持 `nm` 或 `gdb` 查看函数名堆栈。
+      - **调试信息**：`readelf` 未找到 `.debug` 段。这是因为当前处于 **Release** 模式（`-O3 -DNDEBUG`），编译器默认不生成 DWARF 源码级调试信息。
+      - **结论**：这是标准的 Release 构建产物，兼顾了性能（优化开启）和基础可维护性（崩溃时能看到函数名）。
+  - **探测依据**：
+
+    ```bash
+    file …/main_app
+    … not stripped
+    ```
+
+-----
+
+### 1.4 章节最终总结：构建系统与工程配置
+
+至此，我们完成了对 **1.4 构建系统** 的全方位审计。我们确立了该项目的\*\*“构建基线”\*\*：
+
+1. **核心**：CMake 4.1 + Unix Makefiles。
+2. **编排**：**Host(GCC) + Device(Clang) 显式分离**，禁用原生 CUDA 语言支持。
+3. **标志**：适配了 CoreX SDK 的 `-x ivcore` 方言，但缺少 Host 端的架构优化 (`-march=armv8-a`)。
+4. **布局**：产物集中输出到 `build/bin`，RPATH 自动注入，安装规则待补。