I never clearly understood what an ABI is. Please don&#39;t point me to a Wikipedia article. If I could understand it, I wouldn&#39;t be here posting such a lengthy post.

This is my mindset about different interfaces:

A TV remote is an interface between the user and the TV. It is an existing entity, but useless (doesn&#39;t provide any functionality) by itself. All the functionality for each of those buttons on the remote is implemented in the television set.

&gt; **Interface:** It is an &quot;existing entity&quot; layer between the
&gt; `functionality` and `consumer` of that functionality. An interface by itself
&gt; doesn&#39;t do anything. It just invokes the functionality lying behind.
&gt;
&gt; Now depending on who the user is there are different type of interfaces.
&gt;
&gt; **Command Line Interface (CLI)** commands are the existing entities,
&gt; the consumer is the user and functionality lies behind.
&gt;
&gt;
&gt; `functionality:` my software functionality which solves some
&gt; purpose to which we are describing this interface.
&gt;
&gt; `existing entities:` commands
&gt;
&gt; `consumer:` user
&gt;
&gt;
&gt; **Graphical User Interface(GUI)** window, buttons, etc. are the existing
&gt; entities, and again the consumer is the user and functionality lies behind.
&gt;
&gt;
&gt; `functionality:` my software functionality which solves some problem to which we are describing this interface.
&gt;
&gt; `existing entities:` window, buttons etc..
&gt;
&gt; `consumer:` user
&gt;
&gt;
&gt; **Application Programming Interface(API)** functions (or to be
&gt; more correct) interfaces (in interfaced based programming) are the
&gt; existing entities, consumer here is another program not a user, and again
&gt; functionality lies behind this layer.
&gt;
&gt;
&gt; `functionality:` my software functionality which solves some
&gt; problem to which we are describing this interface.
&gt;
&gt; `existing entities:` functions, Interfaces (array of functions).
&gt;
&gt; `consumer:` another program/application.
&gt;
&gt;
&gt; **Application Binary Interface (ABI)** Here is where my problem starts.
&gt;
&gt; `functionality:` ???
&gt;
&gt; `existing entities:` ???
&gt;
&gt; `consumer:` ???

 - I&#39;ve written software in different languages and provided different kinds of interfaces (CLI, GUI, and API), but I&#39;m not sure if I have ever provided any ABI.

[Wikipedia says:](http://en.wikipedia.org/wiki/Application_binary_interface)

&gt; ABIs cover details such as
&gt;
&gt;  - data type, size, and alignment;
&gt;  - the calling convention, which controls how functions&#39; arguments are
&gt; passed and return values retrieved;
&gt;  - the system call numbers and how an application should make system calls
&gt; to the operating system;
&gt;
&gt; Other ABIs standardize details such as
&gt;
&gt;  - the C++ name mangling,
&gt;  - exception propagation, and
&gt;  - calling convention between compilers on the same platform, but do
&gt; not require cross-platform compatibility.

 - Who needs these details? Please don&#39;t say the OS. I know assembly programming. I know how linking &amp; loading works. I know exactly what happens inside.

 - Why did C++ name mangling come in? I thought we are talking at the binary level. Why do languages come in?

Anyway, I&#39;ve downloaded the [[PDF] System V Application Binary Interface *Edition 4.1 (1997-03-18)*][1] to see what exactly it contains. Well, most of it didn&#39;t make any sense.

 - Why does it contain two chapters (4th &amp; 5th) to describe the [ELF](http://en.wikipedia.org/wiki/Executable_and_Linkable_Format) file format? In fact, these are the only two significant chapters of that specification. The rest of the chapters are &quot;processor specific&quot;. Anyway, I though that it is a completely different topic. Please don&#39;t say that ELF file format specifications *are* the ABI. It doesn&#39;t qualify to be an *interface* according to the definition.

 - I know, since we are talking at such a low level it must be very specific. But I&#39;m not sure how is it &quot;instruction set architecture (ISA)&quot; specific?

 - Where can I find Microsoft Windows&#39; ABI?

So, these are the major queries that are bugging me.

  [1]: http://www.sco.com/developers/devspecs/gabi41.pdf



What is an application binary interface (ABI)?

I know that an *&quot;undefined behaviour&quot;* in C++ can pretty much allow the compiler to do anything it wants. However, I had a crash that surprised me, as I assumed that the code was safe enough.

In this case, the real problem happened only on a specific platform using a specific compiler, and only if optimization was enabled.

I tried several things in order to reproduce the problem and simplify it to the maximum. Here&#39;s an extract of a function called `Serialize`, that would take a bool parameter, and copy the string `true` or `false` to an existing destination buffer.

Would this function be in a code review, there would be no way to tell that it, in fact, could crash if the bool parameter was an uninitialized value?

    // Zero-filled global buffer of 16 characters
    char destBuffer[16];
    
    void Serialize(bool boolValue) {
        // Determine which string to print based on boolValue
        const char* whichString = boolValue ? &quot;true&quot; : &quot;false&quot;;
        
        // Compute the length of the string we selected
        const size_t len = strlen(whichString);
        
        // Copy string into destination buffer, which is zero-filled (thus already null-terminated)
        memcpy(destBuffer, whichString, len);
    }

If this code is executed with clang 5.0.0 + optimizations, it will/can crash.

The expected ternary-operator `boolValue ? &quot;true&quot; : &quot;false&quot;` looked safe enough for me, I was assuming, &quot;Whatever garbage value is in `boolValue` doesn&#39;t matter, since it will evaluate to true or false anyhow.&quot;

I have setup a [Compiler Explorer example](https://godbolt.org/z/DoFmhA) that shows the problem in the disassembly, here the complete example. *Note: in order to repro the issue, the combination I&#39;ve found that worked is by using Clang 5.0.0 with -O2 optimisation.*

    #include &lt;iostream&gt;
    #include &lt;cstring&gt;
    
    // Simple struct, with an empty constructor that doesn&#39;t initialize anything
    struct FStruct {
        bool uninitializedBool;
        
       __attribute__ ((noinline))  // Note: the constructor must be declared noinline to trigger the problem
       FStruct() {};
    };
    
    char destBuffer[16];
    
    // Small utility function that allocates and returns a string &quot;true&quot; or &quot;false&quot; depending on the value of the parameter
    void Serialize(bool boolValue) {
        // Determine which string to print depending if &#39;boolValue&#39; is evaluated as true or false
        const char* whichString = boolValue ? &quot;true&quot; : &quot;false&quot;;
        
        // Compute the length of the string we selected
        size_t len = strlen(whichString);
        
        memcpy(destBuffer, whichString, len);
    }
    
    int main()
    {
        // Locally construct an instance of our struct here on the stack. The bool member uninitializedBool is uninitialized.
        FStruct structInstance;
        
        // Output &quot;true&quot; or &quot;false&quot; to stdout
        Serialize(structInstance.uninitializedBool);
        return 0;
    }

The problem arises because of the optimizer: It was clever enough to deduce that the strings &quot;true&quot; and &quot;false&quot; only differs in length by 1. So instead of really calculating the length, it uses the value of the bool itself, which *should* technically be either 0 or 1, and goes like this:

    const size_t len = strlen(whichString); // original code
    const size_t len = 5 - boolValue;       // clang clever optimization

While this is &quot;clever&quot;, so to speak, my question is: **Does the C++ standard allow a compiler to assume a bool can only have an internal numerical representation of &#39;0&#39; or &#39;1&#39; and use it in such a way?**

Or is this a case of implementation-defined, in which case the implementation assumed that all its bools will only ever contain 0 or 1, and any other value is undefined behaviour territory?

Does the C++ standard allow for an uninitialized bool to crash a program?

I am new to Linux system programming and I came across API and ABI while reading
**Linux System Programming**.

**Definition of API:**

&gt; An API defines the interfaces by which
&gt; one piece of software communicates
&gt; with another at the source level.

**Definition of ABI:**

&gt; Whereas an API defines a source
&gt; interface, an ABI defines the
&gt; low-level binary interface between two
&gt; or more pieces of software on a
&gt; particular architecture. It defines
&gt; how an application interacts with
&gt; itself, how an application interacts
&gt; with the kernel, and how an
&gt; application interacts with libraries.


How can a program communicate at a source level? What is a source level? Is it related to source code in any way? Or the source of the library gets included in the main program?

The only difference I know is API is mostly used by programmers and ABI is mostly used by a compiler.


Difference between API and ABI

In C++,

- Why is a boolean 1 byte and not 1 bit of size?
- Why aren&#39;t there types like a 4-bit or 2-bit integers?

I&#39;m missing out the above things when writing an emulator for a CPU


Why is a boolean 1 byte and not 1 bit of size?

Following links explain x86-32 system call conventions for both UNIX (BSD flavor) &amp; Linux:

* http://www.int80h.org/bsdasm/#system-calls

* http://www.freebsd.org/doc/en/books/developers-handbook/x86-system-calls.html

But what are the x86-64 system call conventions on both UNIX &amp; Linux?

What are the calling conventions for UNIX &amp; Linux system calls (and user-space functions) on i386 and x86-64

Are there any downsides to passing structs by value in C, rather than passing a pointer?

If the struct is large, there is obviously the performancd aspect of copying lots of data, but for a smaller struct, it should basically be the same as passing several values to a function.

It is maybe even more interesting when used as return values. C only has single return values from functions, but you often need several. So a simple solution is to put them in a struct and return that.

Are there any reasons for or against this?

Since it might not be obvious to everyone what I&#39;m talking about here, I&#39;ll give  a simple example.

If you&#39;re programming in C, you&#39;ll sooner or later start writing functions that look like this:

    void examine_data(const char *ptr, size_t len)
    {
        ...
    }
    
    char *p = ...;
    size_t l = ...;
    examine_data(p, l);

This isn&#39;t a problem. The only issue is that you have to agree with your coworker in which the order the parameters should be so you use the same convention in all functions.

But what happens when you want to return the same kind of information? You typically get something like this:

    char *get_data(size_t *len);
    {
        ...
        *len = ...datalen...;
        return ...data...;
    }
    size_t len;
    char *p = get_data(&amp;len);

This works fine, but is much more problematic. A return value is a return value, except that in this implementation it isn&#39;t. There is no way to tell from the above that the function get_data isn&#39;t allowed to look at what len points to. And there is nothing that makes the compiler check that a value is actually returned through that pointer. So next month, when someone else modifies the code without understanding it properly (because he didn&#39;t read the documentation?) it gets broken without anyone noticing, or it starts crashing randomly.

So, the solution I propose is the simple struct

    struct blob { char *ptr; size_t len; }

The examples can be rewritten like this:

    void examine_data(const struct blob data)
    {
        ... use data.tr and data.len ...
    }
    
    struct blob = { .ptr = ..., .len = ... };
    examine_data(blob);

    struct blob get_data(void);
    {
        ...
        return (struct blob){ .ptr = ...data..., .len = ...len... };
    }
    struct blob data = get_data();

For some reason, I think that most people would instinctively make examine_data take a pointer to a struct blob, but I don&#39;t see why. It still gets a pointer and an integer, it&#39;s just much  clearer that they go together. And in the get_data case it is impossible to mess up in the way I described before, since there is no input value for the length, and there must be a returned length.


Are there any downsides to passing structs by value in C, rather than passing a pointer?

Suppose I have three compiled objects, all produced by the *same compiler/version*:

1. A was compiled with the C++11 standard
2. B was compiled with the C++14 standard
3. C was compiled with the C++17 standard

For simplicity, let&#39;s assume all headers were written in C++11, _using only constructs whose semantics haven&#39;t changed between all three standard versions_, and so any interdependencies were correctly expressed with header inclusion and the compiler did not object.

Which combinations of these objects is it and isn&#39;t it safe to link into a single binary? Why?

---
EDIT: answers covering major compilers (e.g. gcc, clang, vs++) are welcome

Is it safe to link C++17, C++14, and C++11 objects

AMD has an ABI specification that describes the calling convention to use on x86-64. All OSes follow it, except for Windows which has it&#39;s own x86-64 calling convention. Why?

Does anyone know the technical, historical, or political reasons for this difference, or is it purely a matter of NIHsyndrome? 

I understand that different OSes may have different needs for higher level things, but that doesn&#39;t explain why for example the register parameter passing order on Windows is `rcx - rdx - r8 - r9 - rest on stack` while everyone else uses `rdi - rsi - rdx - rcx - r8 - r9 - rest on stack`. 

P.S. I am aware of *how* these calling conventions differ generally and I know where to find details if I need to. What I want to know is *why*. 

Edit: for the how, see e.g. the [wikipedia entry][1] and links from there. 


  [1]: http://en.wikipedia.org/wiki/X86_calling_conventions#x86-64_Calling_Conventions

Why does Windows64 use a different calling convention from all other OSes on x86-64?

How do I pass class objects, especially STL objects, to and from a C++ DLL?

My application has to interact with third-party plugins in the form of DLL files, and I can&#39;t control what compiler these plugins are built with. I&#39;m aware that there&#39;s no guaranteed ABI for STL objects, and I&#39;m concerned about causing instability in my application.

How do I safely pass objects, especially STL objects, to and from a DLL?

I am preparing some training materials in C and I want my examples to fit the typical stack model.

What direction does a C stack grow in Linux, Windows, Mac OSX (PPC and x86), Solaris, and most recent Unixes? 

What is the direction of stack growth in most modern systems?

I&#39;m watching Chandler Carruth&#39;s talk in CppCon 2019:

[There are no Zero-Cost Abstractions][1]

in it, he gives the example of how he was surprised by just how much overhead you incur by using an `std::unique_ptr&lt;int&gt;` over an `int*`; that segment starts about at time point 17:25.

You can have a look at the [compilation results][2] of his example pair-of-snippets (godbolt.org) - to witness that, indeed, it seems the compiler is not willing to pass the unique_ptr value - which in fact in the bottom line is just an address - inside a register, only in straight memory.

One of the points Mr. Carruth makes at around 27:00 is that the C++ ABI requires by-value parameters (some but not all; perhaps - non-primitive types? non-trivially-constructible types?) to be passed in-memory rather than within a register.

My questions:

1. Is this actually an ABI requirement on some platforms? (which?) Or maybe it&#39;s just some pessimization in certain scenarios?
2. Why is the ABI like that? That is, if the fields of a struct/class fit within registers, or even a single register - why should we not be able to pass it within that register?
3. Has the C++ standards committee discussed this point in recent years, or ever?

------------

PS - So as not to leave this question with no code:

Plain pointer:
```
void bar(int* ptr) noexcept;
void baz(int* ptr) noexcept;

void foo(int* ptr) noexcept {
    if (*ptr &gt; 42) {
        bar(ptr); 
        *ptr = 42; 
    }
    baz(ptr);
}
```

Unique pointer:
```
using std::unique_ptr;
void bar(int* ptr) noexcept;
void baz(unique_ptr&lt;int&gt; ptr) noexcept;

void foo(unique_ptr&lt;int&gt; ptr) noexcept {
    if (*ptr &gt; 42) { 
        bar(ptr.get());
        *ptr = 42; 
    }
    baz(std::move(ptr));
}
```



  [1]: https://www.youtube.com/watch?v=rHIkrotSwcc
  [2]: https://godbolt.org/z/5yv_41

Why can a T* be passed in register, but a unique_ptr&lt;T&gt; cannot?

### Background

In the last year I was using the nlohmann json library&lt;sup&gt;[1]&lt;/sup&gt; and was cross-compiling on x86_64 using GCC 5.x `arm-linux-gnueabi-*` with no warnings. When I updated GCC to a newer version, GCC would generate pages of cryptic diagnostic notes. For example, here is one of the notes

    In file included from /usr/arm-linux-gnueabi/include/c++/7/vector:69:0,
                 from include/json.hpp:58,
                 from src/write_hsi.cpp:23:
    /usr/arm-linux-gnueabi/include/c++/7/bits/vector.tcc: In member function ‘void std::vector&lt;_Tp, _Alloc&gt;::_M_realloc_insert(std::vector&lt;_Tp, _Alloc&gt;::iterator, _Args&amp;&amp; ...) [with _Args = {nlohmann::basic_json&lt;std::map, std::vector, std::__cxx11::basic_string&lt;char, std::char_traits&lt;char&gt;, std::allocator&lt;char&gt; &gt;, bool, long long int, long long unsigned int, double, std::allocator, nlohmann::adl_serializer&gt;}; _Tp = nlohmann::basic_json&lt;&gt;; _Alloc = std::allocator&lt;nlohmann::basic_json&lt;&gt; &gt;]’:
    /usr/arm-linux-gnueabi/include/c++/7/bits/vector.tcc:394:7: note: parameter passing for argument of type ‘std::vector&lt;nlohmann::basic_json&lt;&gt;, std::allocator&lt;nlohmann::basic_json&lt;&gt; &gt; &gt;::iterator {aka __gnu_cxx::__normal_iterator&lt;nlohmann::basic_json&lt;&gt;*, std::vector&lt;nlohmann::basic_json&lt;&gt;, std::allocator&lt;nlohmann::basic_json&lt;&gt; &gt; &gt; &gt;}’ changed in GCC 7.1
       vector&lt;_Tp, _Alloc&gt;::
       ^~~~~~~~~~~~~~~~~~~
    /usr/arm-linux-gnueabi/include/c++/7/bits/vector.tcc: In member function ‘nlohmann::basic_json&lt;ObjectType, ArrayType, StringType, BooleanType, NumberIntegerType, NumberUnsignedType, NumberFloatType, AllocatorType, JSONSerializer&gt; nlohmann::basic_json&lt;ObjectType, ArrayType, StringType, BooleanType, NumberIntegerType, NumberUnsignedType, NumberFloatType, AllocatorType, JSONSerializer&gt;::parser::parse_internal(bool) [with ObjectType = std::map; ArrayType = std::vector; StringType = std::__cxx11::basic_string&lt;char&gt;; BooleanType = bool; NumberIntegerType = long long int; NumberUnsignedType = long long unsigned int; NumberFloatType = double; AllocatorType = std::allocator; JSONSerializer = nlohmann::adl_serializer]’:
    /usr/arm-linux-gnueabi/include/c++/7/bits/vector.tcc:105:21: note: parameter passing for argument of type ‘__gnu_cxx::__normal_iterator&lt;nlohmann::basic_json&lt;&gt;*, std::vector&lt;nlohmann::basic_json&lt;&gt;, std::allocator&lt;nlohmann::basic_json&lt;&gt; &gt; &gt; &gt;’ changed in GCC 7.1
    _M_realloc_insert(end(), std::forward&lt;_Args&gt;(__args)...);
    ~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

It was easy to find a solution, namely by adding `-Wno-psabi` to the compiler options. In fact, that was the fix implemented in the library.&lt;sup&gt;[2]&lt;/sup&gt;

I understand the basics of Application Binary Interfaces (ABIs) and processor-specific ABIs (psABIs). For reference, this answer&lt;sup&gt;[11]&lt;/sup&gt; gives a quick overview of ABIs:

&gt; An ABI (_**Application Binary Interface**_) is a standard that defines a mapping between low-level concepts in high-level languages and the abilities of a specific hardware/OS platform&#39;s machine code. That includes things like:
&gt; 
&gt;  - how C/C++/Fortran/... **data types** are laid out in memory (data sizes / alignments)
&gt;  - how nested **function calls** work (where and how the information on how to return to a function&#39;s caller is stored, where in the CPU registers and/or in memory function arguments are passed)
&gt;  - how **program startup / initialization** works (what data format an &quot;executable&quot; has, how the code / data is loaded from there, how DLLs work ...)
&gt; 
&gt; The answers to these are:
&gt; 
&gt;  - _language-specific_ (hence you&#39;ve got a C ABI, C++ ABI, Fortran ABI, Pascal ABI, ... even the Java bytecode spec, although targeting a &quot;virtual&quot; processor instead of real hardware, is an ABI),
&gt;  - _operating-system specific_ (MS Windows and Linux on the same hardware use a different ABI),
&gt;  - _hardware/CPU-specific_ (the ARM and x86 ABIs are different).
&gt;  - _evolving over (long) time_ (existing ABIs have often been updated / rev&#39;ed so that new CPU features could be made use of, like, say, specifying how the x86 SSE registers are to be used by apps was of course only possible once CPUs _had_ these regs, therefore existing ABIs needed to be clarified).

So the ABI is the overarching component, and one of its components (the &quot;hardware/CPU-specific&quot; details) is the psABI.

### My Issue

The problem I am having is

 1. I don&#39;t like universally disabling warnings without understanding the implications.
 2. The advice &quot;use `-Wno-psabi` to make the notes go away&quot; seems to be pretty common advice for these types of diagnostic notes that &quot;suddenly appear&quot; after a compiler upgrade.&lt;sup&gt;[2]&lt;/sup&gt;&lt;sup&gt;[3]&lt;/sup&gt;&lt;sup&gt;[4]&lt;/sup&gt; Even the one of the GCC developers suggest doing this.&lt;sup&gt;[5]&lt;/sup&gt;
 3. Neither `-Wpsabi` nor `-Wno-psabi` are documented&lt;sup&gt;[6]&lt;/sup&gt; in the GCC manual.&lt;sup&gt;[7]&lt;/sup&gt;

As a result I am not really sure what exactly `-Wno-psabi` will and will not affect. A related option `-Wabi` *is* documented:&lt;sup&gt;[8]&lt;/sup&gt;

&gt; `-Wabi (C, Objective-C, C++ and Objective-C++ only)`
&gt;
&gt;    Warn when G++ it generates code that is probably not compatible with the vendor-neutral C++ ABI...
&gt;
&gt; It also warns about psABI-related changes. The known psABI changes at this point include: 
&gt;
&gt; - For SysV/x86-64, unions with long double members are passed in memory as specified in psABI. For example: 
&gt;
&gt; `    union U {`
&gt; `     long double ld;`
&gt; `     int i;`
&gt; `    };`
&gt;
&gt; `union U` is always passed in memory.

My understanding of this all is

1. `-Wabi` will generate warnings when there is a psABI change.
2. GCC 7 fixed an ABI bug&lt;sup&gt;[9]&lt;/sup&gt; introduced in GCC 5 that affects ARM targets.
    - In the release notes it is stated &quot;this is an ABI change.&quot;&lt;sup&gt;[10]&lt;/sup&gt;
    - For some reason the release notes state that the related diagnostic notes are generated when using the undocumented `-Wpsabi`, not the documented `-Wabi`.
    - This ABI change is not mentioned in the manual.
3. Putting together &quot;this is an ABI change&quot; and &quot;use `-Wpsabi`&quot;, it appears to me this is *specifically* a psABI change, not a different kind of ABI change. (In reality it is a change in GCC&#39;s implementation of the psABI, not the psABI itself)

I know that documentation isn&#39;t always up to date, especially for something that is a known undocumented option. But my concern is that &quot;use `-Wno-psabi`&quot; seems to be the standard response for several different kinds of these cryptic diagnostic notes. But, in my basic understanding of ABIs, isn&#39;t an ABI change a big deal? Shouldn&#39;t I be concerned about an ABI change, rather than just making the message go away? Between the undocumented stuff and some of the finer details of ABI vs psABI, I&#39;m not really sure...

For example, if I add `-Wno-psabi` to my makefile to make those notes go away, what if there is another ABI change in the future that *does* affect my project? Have I effectively silenced future warnings or notes that may be important?

Also, even though we are told &quot;if you recompile all the code, there is nothing to worry about,&quot;&lt;sup&gt;[5]&lt;/sup&gt; what exactly is &quot;all the code&quot;? Is that my source code? glibc? Any other system-wide shared library I might be using?

### References

1. https://github.com/nlohmann/json
2. https://github.com/nlohmann/json/issues/658
3. https://stackoverflow.com/a/48149400
4. https://stackoverflow.com/a/13915796/10270632
5. https://gcc.gnu.org/ml/gcc/2017-05/msg00073.html
6. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81831
7. https://gcc.gnu.org/onlinedocs/gcc-8.2.0/gcc
8. https://gcc.gnu.org/onlinedocs/gcc-8.2.0/gcc/C_002b_002b-Dialect-Options.html
9. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77728
10. https://gcc.gnu.org/gcc-7/changes.html
11. https://stackoverflow.com/a/8063350

What exactly does GCC&#39;s -Wpsabi option do? What are the implications of supressing it?

From wiki [Executable and Linkable Format](https://en.wikipedia.org/wiki/Executable_and_Linkable_Format):

&gt; The segments contain information that is necessary for runtime execution of the file, while sections contain important data for linking and relocation. Any byte in the entire file can be owned by at most one section, and there can be orphan bytes which are not owned by any section.

But what is the difference between section and segment? 
In an executable ELF file, does a segment contain one or more sections?

What&#39;s the difference of section and segment in ELF file format

The x86-64 System V ABI (used on everything except Windows) used to live at http://x86-64.org/documentation/abi.pdf, but that site has now fallen off the internet.

Is there a new authoritative home for the document?


Where is the x86-64 System V ABI documented?

I am constantly getting this warning while building my android studio code using terminal command `gradle clean assembleRelease`:

`Unable to strip library &#39;lib.so&#39; due to missing strip tool for ABI &#39;ARMEABI&#39;. Packaging it as is.`

Please help me on how to get this warning resolved.

Note: I know this won&#39;t affect the behaviour of my app, but my APK is too bulky and this will surely help me reduce APK size. So I need this resolved.

Android Studio : Missing Strip Tool

I&#39;m having some trouble understanding the difference between caller and callee saved registers and when to use what. 

I am using the MSP430
:

procedure:

    mov.w #0,R7 
    mov.w #0,R6 
    add.w R6,R7 
    inc.w R6 
    cmp.w R12,R6 
    jl l$loop 
    mov.w R7,R12
    ret

the above code is a callee and was used in a textbook example so it follows the convention. R6 and R7 are callee saved and R12 is caller saved. My understanding is that the callee saved regs aren&#39;t &quot;global&quot; in the sense that changing its value in a procedure will not affect it&#39;s value outside the procedure. This is why you have to save a new value into the callee reg at the beginning.

R12, the caller saved is &quot;global&quot;, for lack of better words. What the procedure does has a lasting effect on R12 after the call.

Is my understanding correct? Am I missing other things?

What are callee and caller saved registers?

`int 0x80` on Linux always invokes the 32-bit ABI, regardless of what mode it&#39;s called from:  args in `ebx`, `ecx`, ... and syscall numbers from `/usr/include/asm/unistd_32.h`.   (Or crashes on 64-bit kernels compiled without `CONFIG_IA32_EMULATION`).

**64-bit code should use `syscall`**, with call numbers from `/usr/include/asm/unistd_64.h`, and args in `rdi`, `rsi`, etc.  See https://stackoverflow.com/questions/2535989/what-are-the-calling-conventions-for-unix-linux-system-calls-on-x86-64.  If your question was marked a duplicate of this, **see that link for details on how you *should* make system calls in 32 or 64-bit code.**  If you want to understand what exactly happened, keep reading.

(For an example of 32-bit vs. 64-bit `sys_write`, see https://stackoverflow.com/questions/22503944/using-interrupt-0x80-on-64-bit-linux)

---

`syscall` system calls are faster than `int 0x80` system calls, so use native 64-bit `syscall` unless you&#39;re writing polyglot machine code that runs the same when executed as 32 or 64 bit.  (`sysenter` always returns in 32-bit mode, so it&#39;s not useful from 64-bit userspace, although it is a valid x86-64 instruction.)

Related: [**The Definitive Guide to Linux System Calls** (on x86)][1] for how to make `int 0x80` or `sysenter` 32-bit system calls, or `syscall` 64-bit system calls, or calling the vDSO for &quot;virtual&quot; system calls like `gettimeofday`.  Plus background on what system calls are all about.

---

Using `int 0x80` makes it possible to write something that will assemble in 32 or 64-bit mode, so it&#39;s handy for an `exit_group()` at the end of a microbenchmark or something.

Current PDFs of the official i386 and x86-64 System V psABI documents that standardize function and syscall calling conventions are linked from https://github.com/hjl-tools/x86-psABI/wiki/X86-psABI.

See the [tag:x86] tag [wiki][2] for beginner guides, x86 manuals, official documentation, and performance optimization guides / resources.

----

But since people keep posting questions with code that uses [`int 0x80` in 64-bit code][3], or accidentally [building 64-bit binaries][4] from source written for 32-bit, I wonder **what *exactly* does happen on current Linux?**

**Does `int 0x80` save/restore all the 64-bit registers?  Does it truncate any registers to 32-bit?  What happens if you pass pointer args that have non-zero upper halves?**

**Does it work if you pass it 32-bit pointers?**


  [1]: https://blog.packagecloud.io/eng/2016/04/05/the-definitive-guide-to-linux-system-calls/
  [2]: https://stackoverflow.com/tags/x86/info
  [3]: https://stackoverflow.com/questions/14033028/sys-read-syscall-vs-int-0x80-in-gnu-assembler
  [4]: https://stackoverflow.com/questions/36861903/assembling-32-bit-binaries-on-a-64-bit-system-gnu-toolchain

What happens if you use the 32-bit int 0x80 Linux ABI in 64-bit code?

Please explain the difference between `x86`, `x32` and `x64`? Its a bit confusing when it comes to `x86` and `x32` because most of the time 32-bit programs run on x86... 

Difference between x86, x32, and x64 architectures?

I believe I understand how the linux x86-64 ABI uses registers and stack to pass parameters to a function (cf. [previous ABI discussion](https://stackoverflow.com/questions/2535989/what-are-the-calling-conventions-for-unix-linux-system-calls-on-x86-64/2538212#2538212)). What I&#39;m confused about is if/what registers are expected to be preserved across a function call. That is, what registers are guarenteed not to get clobbered?

What registers are preserved through a linux x86-64 function call

For my Android-app I&#39;m using the ABI &quot;x86&quot; and &quot;armeabi&quot; right now.
The armeabi is used for all ARM-devices, including armv7a and arm64-v8a.

Now I would like to remove the &quot;armeabi&quot; and just continue with &quot;x86&quot; and &quot;armeabi-v7a&quot;.

I haven&#39;t found any hint in the docs, that ARMv8 is also compatible with ARMv7 - can anyone confirm that my app will still work on devices running arm64-v8a, if I don&#39;t offer an armeabi but now an armeabi-v7a-library?



All Abi Solutions on Gang of Coders

Total of 20 Abi Solutions