c++ ABI标准遵从性/任意名称混淆

C++ ABI standards compliance w/ arbitrary name mangling

本文关键字：任意名 ABI 标准 c++ 更新时间：2023-10-16

问题标题有点像钩子。我已经知道没有c++标准ABI。话虽如此，我并没有欺骗你们这些渴望获得支持的人。我想知道c++ ABI是否有任何限制。这似乎很常见，例如，至少一个类的名称在ABI名称中某处被打乱。

一个更明确的问题

假设我有一个针对所有字符串的无冲突哈希函数。然后，假设GCC在其名称篡改中又添加了一个步骤:将当前修改后的名称的哈希值附加到下划线。这将破坏几乎所有的东西，但是GCC仍然会像以前一样符合c++标准吗?

编辑:

好吧，显然"明确的问题"这一点是一个不合适的子标题。我非常想了解更多关于人们遵循的通用ABI标准的信息。这是因为我用Mingw32编译的二进制文件与我用MSVC编译的二进制文件成功地链接在一起。

它仍然符合ISO c++标准，该标准甚至没有在规范文本中提到名称混淆，更不用说限制如何做到这一点了，但它不符合GCC在大多数平台上使用的跨供应商ABI标准。

标准故意对这个问题保持沉默:所有与ABI和名称混淆有关的都是特定于实现的。我认为，关于这个主题最接近信息的东西是:

7.5/1 [dcl.link]

所有函数类型、带有外部链接的函数名和变量具有外部链接的名称具有语言链接。[注:Some of。与具有语言链接的实体相关联的属性是具体到每个实现，这里不做描述。为例如，特定的语言链接可能与表示对象和函数名称的特殊形式外部链接，或具有特定调用约定等 - end注意]

因此，每个实现都可以自由地做任何它想做的关于名称篡改的事情，只要篡改的名称在底层操作系统上有效。

是的，它当然仍然是符合标准的。然而，尽管与标准兼容是一件很棒的事情，但它肯定不是最重要的。

这样的更改会破坏每个用c++编写并使用上述GCC版本编译的库或应用程序的向后兼容性。向后兼容性对GCC开发人员来说是非常重要的，他们花了相当多的时间在邮件列表上(只是看看)讨论即使是非常小的ABI变化在面对这种破坏时的相对好处。通常情况下，他们会不遗余力地提供可以保持向后兼容性的解决方案。

直觉告诉我，如果更改了这个策略，大多数发行版都会拒绝升级。可能会让他们中的一群人移动到clang甚至…

至少我们可以放心，他们会添加另一个-f选项，将关闭新的"功能"。