AMD64 Linux下编译器用32位寄存器传指针致段错误的原因与解决

这个问题的核心是编译器对EC_KEY_get0_group的返回类型判断错误，导致64位环境下用32位寄存器传递64位指针，最终截断地址引发段错误。下面分原因和解决办法详细说明：

可能的原因 #

1. 函数隐式声明或声明不匹配 #

这是最常见的情况：如果你的编译单元没有正确包含BoringSSL中EC_KEY_get0_group的头文件，编译器会默认该函数返回int（C语言的旧规则）。在64位系统中，int是32位，所以编译器会用32位寄存器%eax传递返回值，64位指针被截断后变成无效地址，调用EC_GROUP_get_curve_name时自然触发段错。

另外，也可能是你修改BoringSSL时不小心改动了函数声明，比如把EC_GROUP*改成了int，或者头文件中的声明和实际函数实现不匹配。

2. 混合32位/64位编译选项 #

如果Chromium整体是64位编译，但你修改的BoringSSL部分用了32位编译选项（比如-m32），或者反过来，就会导致函数调用的ABI不兼容。32位环境下指针是32位，用%eax传递，但64位环境下需要用%rax，混合编译就会出现这种截断问题。

3. ABI或调用约定被错误修改 #

虽然64位Linux/macOS下默认使用System V AMD64 ABI（返回指针用%rax），但如果函数被错误标记了特殊调用约定（比如__attribute__((stdcall))），或者编译时强制修改了ABI规则，也可能导致寄存器使用错误。

解决办法 #

1. 确保函数声明正确且被正确包含 #

• 在调用EC_KEY_get0_group的代码文件顶部，确认已经包含了BoringSSL的EC模块头文件：

  #include <openssl/ec.h> // 或者BoringSSL对应的头文件路径
  

• 检查头文件中EC_KEY_get0_group的声明是否为：

  EC_GROUP *EC_KEY_get0_group(const EC_KEY *key);
  

  避免任何把返回类型改成int或其他32位类型的错误。

2. 统一编译架构选项 #

• 确认Chromium和修改后的BoringSSL都使用64位编译选项：
  • GCC/Clang下添加-m64（默认在64位系统上是开启的，但如果手动指定了-m32要去掉）
  • 检查Chromium的GN配置或Makefile，确保所有目标的target_cpu设置为"x64"（或对应64位架构），没有混合32位目标。

3. 启用严格编译警告并修复 #

• 开启编译器的严格警告，比如在编译选项中添加：

  -Wall -Wextra -Werror -Wimplicit-function-declaration -Wpointer-truncation
  

  这些警告会在编译阶段就发现隐式声明、指针截断等问题，避免运行时的段错。如果编译出现警告，按照提示修复即可。

4. 验证符号类型 #

• 用nm工具检查编译后的BoringSSL库或目标文件，确认EC_KEY_get0_group的符号类型正确：

  nm -D libcrypto.so | grep EC_KEY_get0_group
  

  输出应该显示类似T EC_KEY_get0_group（T表示文本段的函数），如果是其他类型或者返回类型不匹配，说明编译或链接有问题。

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