标签: abi

前段时间,GCC> = 5和Clang> = 4编译器改变了他们的版本号的语义,因此任何非bugfix版本的主版本号都会增加.

Apple在ABI兼容性或任何其他范围方面是否遵循任何带有clang编译器的版本模式？我想知道apple-clang 9.0ABI是否兼容9.1等等.

这就是维基百科所说的:

在计算机软件中,应用程序二进制接口(ABI)描述应用程序(或任何类型)程序与操作系统或另一应用程序之间的低级接口.

ABI涵盖了数据类型,大小和对齐等细节; 调用约定,它控制函数参数的传递方式并返回检索的值; 系统调用号码以及应用程序应如何向操作系统进行系统调用; 并且在完整的操作系统ABI的情况下,目标文件,程序库等的二进制格式.完整的ABI(例如英特尔二进制兼容性标准(iBCS))允许来自支持该ABI的一个操作系统的程序在不修改任何其他此类系统的情况下运行,前提是存在必要的共享库,并且满足类似的先决条件.

我猜ABI是一种约定或标准,编译器/链接器使用此约定来生成目标代码.是对的吗？如果是这样,谁制定了这些约定(公司或某个组织)？什么时候没有ABI？我们可以参考哪些关于这些ABI的文件？

AMD64 psABI过去曾在x86-64.org上托管.

我有一份pdf文件,它明确地说:

该体系结构规范可在网站 http://www.x86-64.org/documentation上获得.

但是http://www.x86-64.org已经很长时间了.至少几个月.

有谁知道最新的psABI可以从哪里拿走？

当Microsoft最初于2012年9月发布Visual Studio 2012时,他们宣布了他们计划更频繁地为Visual Studio提供更新的计划.从那时起,他们于2012年11月发布了Visual Studio 2012 Update 1(Visual Studio 2012.1),并于2013年4 月发布了Visual Studio 2012 Update 2(Visual Studio 2012.2).

我的问题是:更新是否引入了对C++ ABI的任何更改(关于最初的VS2012版本)？链接.lib不同的VS2012版本是否安全？

我在互联网上搜索了一段时间,但未找到微软的任何明确声明.有些消息来源提到C++代码生成中的一些错误已得到修复,但我认为这并不意味着ABI的变化？

强烈建议在创建64位内核(对于x86_64平台)时,指示编译器不要使用用户空间ABI所执行的128字节红区.(对于GCC,编译器标志是-mno-red-zone).

如果启用了内核,则内核不会是中断安全的.

但那是为什么呢？

从1999版开始,ISO C标准定义了一个标准头<stdint.h>,其中定义了typedef intmax_t和uintmax_t.它们分别指定"能够表示任何(有符号|无符号)整数类型的任何值的(有符号|无符号)整数类型".

例如,如果像典型的是,最宽的符号和无符号整数类型是long long int和unsigned long long int,这两者通常是64位,则intmax_t和uintmax_t在可能被定义<stdint.h>如下:

typedef long long int intmax_t;
typedef unsigned long long int uintmax_t;

有一组预定义的有限符号和无符号整数类型,从的signed,unsigned和普通char高达signed和unsigned long long int.

C99和C11还允许实现定义扩展的整数类型,这些类型不同于任何标准类型,并且具有实现定义的关键字的名称.

gcc和clang在某些但不是所有目标上都支持类型__int128和unsigned __int128.这些行为类似于128位整数类型,但它们不被视为扩展整数类型,并且两个编译器的文档都声明它们不支持任何扩展整数类型.因为这些都不是整数类型的标准定义的术语,该类型定义intmax_t和uintmax_t是64位类型的,而不是128位的类型.

这些都不违反C标准(实现不需要具有任何扩展的整数类型,并且只要它们不破坏任何严格符合的程序,它们就被允许具有任意扩展).但在我看来,它将使完美感__int128和unsigned __int128被视为扩展整数类型,以及intmax_t和uintmax_t为128位的类型. …

这可能是一个重复的问题,但我无法找到它.我想知道我们如何使用代码获得手机的ABI.我知道gradle文件中可能有不同的接口.但问题是如何才能准确获取某个设备的ABI,以便我可以使用SuperSU手动将其复制到system/lib /文件夹.谢谢.

android.productFlavors {
        // for detailed abiFilter descriptions, refer to "Supported ABIs" @
        // https://developer.android.com/ndk/guides/abis.html#sa
        create("arm") {
            ndk.abiFilters.add("armeabi")
        }
        create("arm7") {
            ndk.abiFilters.add("armeabi-v7a")
        }
        create("arm8") {
            ndk.abiFilters.add("arm64-v8a")
        }
        create("x86") {
            ndk.abiFilters.add("x86")
        }
        create("x86-64") {
            ndk.abiFilters.add("x86_64")
        }
        create("mips") {
            ndk.abiFilters.add("mips")
        }
        create("mips-64") {
            ndk.abiFilters.add("mips64")
        }
        // To include all cpu architectures, leaves abiFilters empty
        create("all")
    }

作为Linux发行版中的下游维护者,我通常维护的一些软件包开始在其代码库中使用C++ 11特性.所有这些都依赖于Linux发行版打包的不同库.

将C++ 11代码与C++ 98和AFAIK混合时,可能会出现ABI问题,当编译软件生成包时,大多数当前主要的Linux发行版都默认不启用C++ 11标志.

问题是:主要的Linux发行版如何处理C++ 11代码的输入？在使用系统库时,是否有一种可靠的方法来检查或避免ABI的这些问题？

谢谢.

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0135r0.html

上述"保证副本Elision"提案在2016年6月在芬兰奥卢举行的会议上被投票选入C++工作文件,然后被投票作为委员会草案出版.希望明年能够成为C++ 17标准的出版物.

该提案阐明了涉及临时对象的各种值类别,以在某些用例中强制执行复制构造函数调用.

我的问题是"这些新要求可能会破坏编译器的ABI兼容性,这些编译器可能以前没有在这些情况下完成复制,或者是以不符合新要求的方式实现的吗？"

我正在考虑初始化之类的东西,当创建对象时可以内联,而不是在跨越编译单元边界时.

我想知道编译器是否会在32位和64位系统上使用不同的填充，因此我在一个简单的VS2019 C ++控制台项目中编写了以下代码：

struct Z
{
    char s;
    __int64 i;
};

int main()
{
    std::cout << sizeof(Z) <<"\n"; 
}

我对每个“平台”设置的期望：

x86: 12
X64: 16

实际结果：

x86: 16
X64: 16

由于x86上的存储字大小为4个字节，因此这意味着它必须以i两个不同的字存储字节。所以我认为编译器将以这种方式进行填充：

struct Z
{
    char s;
    char _pad[3];
    __int64 i;
};

所以我可以知道背后的原因是什么？

1. 是否与64位系统具有前向兼容性？
2. 由于在32位处理器上支持64位数字的限制？