通义千问协助分析openHarmony内核编译故障记录

本文主要是介绍通义千问协助分析openHarmony内核编译故障记录，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

drivers/hdf/khdf/manager/../../../..//framework/utils/src/hdf_sbuf.c:271:6: 错误： ‘-mgeneral-regs-only’ is incompatible with floating-point argument

这个编译错误提示指出，在编译源文件 "hdf_sbuf.c"（位于 "drivers/hdf/khdf/manager/../../../..//framework/utils/src/" 路径下）的第 271 行第 6 列位置，由于使用了 -mgeneral-regs-only 编译选项，导致与该行代码中涉及浮点数操作的函数或指令不兼容。

-mgeneral-regs-only 是 gcc 的一个编译选项，它限制编译器只能使用通用寄存器，不使用浮点寄存器或其他特定架构的寄存器。如果在代码中有浮点运算，而编译时启用了这个选项，就会出现上述错误。

解决这个问题的方法通常是检查并调整编译选项，如果你确实需要在代码中进行浮点运算，那么应该移除 -mgeneral-regs-only 这个选项；若希望保持此选项以满足特定优化需求，则应审查并修改源码，确保涉及浮点数的部分能够通过仅使用通用寄存器完成计算。

drivers/hdf/khdf/platform/mipi_dsi/mipi_tx_dev.c:232:16: 错误： 函数声明不是一个原型 [-Werror=strict-prototypes]

这个编译错误是来自C语言编程中的一个警告升级为错误的情况。在C语言编程规范中，函数声明应当具有明确的类型，包括返回值类型和参数列表及其类型。编译器在处理 "drivers/hdf/khdf/platform/mipi_dsi/mipi_tx_dev.c" 文件第 232 行第 16 列的位置发现了一个函数声明，但这个声明没有遵循严格的原型规则。

错误 -Werror=strict-prototypes 表示你启用了将所有关于非严格原型的警告视为错误的编译选项。这意味着，即使是一个只声明了函数名但没有指定参数类型和数量的函数声明也会被当作错误对待。

要修复这个错误，请确保你的函数声明形式如下：

C

ReturnType function_name(ParamType1 param1, ParamType2 param2, ...);

例如：

C

int mipi_tx_some_func(int arg1, char *arg2);

请根据实际代码情况，补充或修正 mipi_tx_dev.c 文件中第 232 行的函数声明，使其包含完整的参数类型信息。

这是头文件没有函数声明导致的？

不一定是因为头文件没有函数声明导致的。虽然通常我们在头文件中声明函数以便于其他文件调用，但这里的错误提示“函数声明不是一个原型”指的是在源文件（本例中是 "mipi_tx_dev.c"）中直接定义的某个函数在其首次声明时，未提供充分的类型信息。

例如，错误可能是由于以下这种情况：

C

// 不符合严格原型规定的函数声明
void myFunc(); // 缺少参数类型// 正确的函数声明应该像这样（假设它接受两个整数作为参数）
void myFunc(int arg1, int arg2);// 或者在函数定义时直接给出原型
void myFunc(int arg1, int arg2) {// 函数体...
}

所以，你需要检查 "mipi_tx_dev.c" 文件的第 232 行，确认相应的函数声明是否提供了所有参数的类型以及返回值类型。如果是从头文件中引入的函数声明也需确保其符合严格的原型规定。

void myFunc(void); 这种才可以？

是的，对于无参数的函数，正确的函数声明应该是：

C

void myFunc(void);

这里的 void 表示函数不接受任何参数。这样的声明符合 C 语言的“严格原型”规定，编译器可以据此准确地进行类型检查和函数调用匹配。

因此，在 "mipi_tx_dev.c" 文件中，如果有一个不需要参数的函数，它的声明或定义应该是：

C

// 声明部分
void mipi_tx_some_func(void);// 定义部分
void mipi_tx_some_func(void) {// 函数体...
}

这样就不会触发 -Werror=strict-prototypes 的编译错误了。

/tmp/ccnxLclV.s:131: 错误： missing immediate expression at operand 1 -- `dsb '

您遇到的错误是在汇编层面的编译错误，提示信息表示在 /tmp/ccnxLclV.s 文件的第 131 行出现了问题，具体错误是“缺少立即数表达式”，在汇编指令 dsb 的第一个操作数位置。

dsb（Data Synchronization Barrier）是一种 ARM 架构下的内存屏障指令，用于确保数据同步，防止乱序执行。在使用 dsb 指令时，一般不会带有立即数作为操作数。例如，一个典型的 dsb 指令使用可能如下：

Assembly

dsb sy

这里，“sy”代表的是内存屏障的类型（比如“同步数据存储”），而不是立即数。

错误可能的原因有：

1. 如果您确实需要传入一个立即数作为 dsb 的参数，那么这可能是对指令用法的误解。
2. 可能是源代码中的宏或者预处理器指令展开后出现了语法错误，导致 dsb 后面没有正确跟随所需的参数。

建议您检查相关的汇编代码片段，确保 dsb 指令的使用符合 ARM 架构的文档说明。如果没有意传递立即数，去掉错误的立即数符号即可。如果有意为之，请核实具体的硬件平台和架构文档，以确定如何正确使用 dsb 指令。

以下是C源代码： static void OsalDsb(void) { dsb(); }

针对您的 C 源代码片段：

C

static void OsalDsb(void)
{dsb();
}

这段代码是为了在 ARM 架构上实现数据同步屏障（Data Synchronization Barrier）。然而，在纯 C 语言环境下，dsb() 并不是标准库提供的函数，而是需要通过内联汇编（inline assembly）来实现。在 ARM GCC 编译器中，您可以这样做：

C

static inline void OsalDsb(void)
{__asm__ volatile("dsb sy");
}

这里，__asm__ volatile("dsb sy"); 是一个内联汇编语句，它告诉编译器插入一个内存屏障指令，并且保证这条指令不会被编译器优化掉。dsb sy 指令执行的是一个同步数据存储屏障，确保在此指令之前的所有内存访问都已完成。

请注意，对于不同架构或不同的编译器，实现方式可能会有所不同。在某些情况下，您可能还需要包含特定的头文件来支持这些内联汇编指令。但在大多数现代嵌入式开发环境中，如基于 ARM Cortex-M 或 Cortex-A 系列处理器的开发，上述内联汇编代码应该可以正常工作。

这看起来像是一个编译器选项错误？

抱歉，我之前的回答集中在了解释和解决 C 代码中的 dsb() 指令问题。现在回到您最初的编译错误：

Code

/tmp/ccnxLclV.s:131: 错误： missing immediate expression at operand 1 -- `dsb `

这个错误并不是由于编译器选项设置错误造成的，而是编译器在生成汇编代码阶段遇到了问题。dsb 指令在 ARM 架构中是用来实现内存屏障的，通常它不需要立即数作为参数。

错误信息表明在汇编代码中，dsb 指令后面可能遗漏了必要的参数，或者是参数格式不正确。在 ARM 架构中，dsb 指令的基本格式如下：

Assembly

dsb [option]

这里的 [option] 是可选的内存屏障类型，例如 sy 表示同步数据存储。

因此，需要检查相关 C 代码（特别是涉及到内存屏障的地方）是否正确使用了内联汇编或特定的 API 来调用 dsb 指令，同时确保编译器正确处理了这个汇编指令。如果 C 代码中使用了类似 __asm__ volatile("dsb"); 的写法，理论上应当提供内存屏障类型，例如 "dsb sy"。当然，这也取决于编译器和目标架构的具体实现。

我在arch/arm64/include/asm/barrier.h找到以下代码：#define isb() asm volatile("isb" : : : "memory") #define dmb(opt) asm volatile("dmb " #opt : : : "memory") #define dsb(opt) asm volatile("dsb " #opt : : : "memory")

这段代码来自于 ARM64 架构下的 Linux 内核头文件 arch/arm64/include/asm/barrier.h，其中定义了三个用于实现内存屏障的宏：

• isb(): 这个宏会生成一条 Instruction Synchronization Barrier (ISB) 指令，它的作用是强制完成所有之前发出的内存访问操作，并且刷新指令流水线，确保任何后续的指令从内存中获取的是最新的版本。

• dmb(opt): 定义了一个 Data Memory Barrier (DMB) 指令，这里的 #opt 是一个字符串化参数，代表了 DMB 的不同选项，比如 ish, ishst, oshst 等，这些选项用来指定不同的内存屏障类型，以控制特定种类的数据访问顺序。当使用此宏时，实际调用时需要传递具体的 DMB 类型，如 dmb(ish)。

• dsb(opt): 同样定义了一个 Data Synchronization Barrier (DSB) 指令，功能与 DMB 类似但更强大，它不仅保证了数据访问的顺序性，还确保了所有对内存的读写操作都已经完成。同样地，这里也需要传入具体的 DSB 类型。

这三个宏后面都跟有 : : : "memory"，这是 GCC 内联汇编语法的一部分，表示这些汇编指令没有输入输出操作数，但是会影响内存操作的顺序，即告诉编译器存在一个内存屏障，阻止它对内存操作进行重排序优化。

所以，如果您在代码中直接使用 dsb() 而没有传入具体选项，就像上面错误提示里那样，将会导致编译错误，因为 dsb 需要一个具体的选项参数。正确的使用应该是 dsb(sy) 或者其他有效的 DSB 类型选项。

dmb()函数也是调整为dmb(sy)?

dmb() 函数（实际上是宏）在使用时确实需要一个具体的同步选项作为参数，例如可以是 sy，这代表“System”同步选项。在 ARMv8-A 架构中，dmb sy 可以实现最全面的数据内存屏障效果，它可以确保所有类型的数据访问（包括普通数据、I/O 和 coherent 内存系统）的顺序都被正确遵守。

因此，如果你想要执行一个全面的数据内存屏障操作，你应该这样使用：

C

dmb(sy);

不过，请注意实际使用时应根据你的具体需求和硬件特性来选择合适的同步选项。在某些场景下，可能需要用到更为精确的同步类型，比如 ish（Inner Shareable）、ishst（Inner Shareable Store）等。

很好，成功编译出内核Image

太好了！我很高兴听到您已经成功解决了编译问题，并编译出了内核 Image。如果您在后续的开发过程中有任何疑问或遇到新的挑战，请随时提问，我会尽我所能为您提供帮助。祝您在项目开发中一切顺利！

这篇关于通义千问协助分析openHarmony内核编译故障记录的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！

---