System V Application Binary Interface [pdf](ccs.neu.edu)
ccs.neu.edu
System V Application Binary Interface [pdf]
https://ccs.neu.edu/home/ntuck/courses/2021/01/cs3650/asm/x86-64-sysv-abi.pdf
8 comments
This should be required reading for low level engineers, along with the Itanium C++ ABI.
> Itanium C++ ABI
Are you being sarcastic? Why would that be relevant? Linux uses the System V ABI...
Are you being sarcastic? Why would that be relevant? Linux uses the System V ABI...
The Itanium C++ ABI, despite its name, is a cross-architecture ABI for C++ that's basically used by every C++ compiler except for MSVC [1], although the details in exception handling do vary a little bit more.
Historically, C++ compilers all did their own thing with C++ ABIs. When Intel was pushing Itanium hard, they wanted to avoid incompatibility issues, so they created a standardized ABI for all the C++ vendors on Itanium to agree on. Later, g++ needed to revise its internal ABI for various reasons, and given that it already supported the Itanium ABI for Itanium, they opted to extend the ABI definition to all architectures rather than create their own. Since then, all the major compilers [sans MSVC] have adopted the Itanium ABI for C++ cross-architecture, and it's still maintained today despite Itanium processors themselves no longer receiving that maintenance.
It's really at the point now that if you say "Itanium ABI," people will assume you're talking about the cross-architecture C++ ABI and not the Itanium-specific processor ABI for any OS.
[1] The MSVC ABI is not officially documented publicly, and given some of the bugs in MSVC found when Clang was attempting to reverse engineer it, I'm dubious that Microsoft itself has any internal documentation either. Note that g++ on Windows will use the Itanium C++ ABI instead of the MSVC ABI.
Historically, C++ compilers all did their own thing with C++ ABIs. When Intel was pushing Itanium hard, they wanted to avoid incompatibility issues, so they created a standardized ABI for all the C++ vendors on Itanium to agree on. Later, g++ needed to revise its internal ABI for various reasons, and given that it already supported the Itanium ABI for Itanium, they opted to extend the ABI definition to all architectures rather than create their own. Since then, all the major compilers [sans MSVC] have adopted the Itanium ABI for C++ cross-architecture, and it's still maintained today despite Itanium processors themselves no longer receiving that maintenance.
It's really at the point now that if you say "Itanium ABI," people will assume you're talking about the cross-architecture C++ ABI and not the Itanium-specific processor ABI for any OS.
[1] The MSVC ABI is not officially documented publicly, and given some of the bugs in MSVC found when Clang was attempting to reverse engineer it, I'm dubious that Microsoft itself has any internal documentation either. Note that g++ on Windows will use the Itanium C++ ABI instead of the MSVC ABI.
Here's an internal ABI doc which escaped Redmond at one point:
http://www.openrce.org/articles/files/jangrayhood.pdf
I believe there were other ABI docs but the official version of that was what I was given.
Maybe you have some reading to do
Although I think the only updates since the version linked here are effectively editorial in note. The last big updates are adding AMX registers to the ABI, and the addition of microarchitecture levels, both of which are in this version.