How to detect ABI at compile time?

Question

Is there a way to detect ABI in C/C++ at compile time? I know there are macros for OS and CPU architecture. Are there similar macros (or some other way) for ABI?

Answer 1

The notion of ABI is not known to standard specification like C11 or C++14. It is an implementation thing.

You could on Linux use feature_test_macros(7).

You could consider improving your build procedure (e.g. your Makefile, etc...). You might run some shell script detecting features (like autoconf generated configure scripts do). Notice that some C or C++ code (e.g. header files, etc...) might be generated at build time (for examples: by bison, moc, rpcgen, swig, ...), perhaps by your own utilities or scripts. Use a good enough build automation tool (with care, GNU make and ninja are able to deal with generated C++ or C code and manage their generation and the dependencies).

^{Don't confuse compilation with build; the compilation commands running a compiler are just parts of the build process.}

Some platforms accept several ABIs. E.g. my Linux/Debian/Sid/x86-64 desktop with a Linux 4.13 kernel can run x86 32 bits ELF executable, x86-64 64 bits ELF, probably some old a.out format from the 1980s, and also x32 ABI. With binfmt_misc I can add even more ABIs. See x86 psABI for a list of several ABI documentations.

BTW, the current trend is to try writing portable code. Perhaps using frameworks like Qt or POCO or Glib (and many others) could hide the ABI details to your application.

In some cases, libffi might be helpful too.

In general, once you know your OS and your architecture, you can practically -most of the time- deduce the ABI.

If you really want your ABI, then a possible Linux specific way might be to run file(1) on the current executable. I don't recommend doing that, but you could try (using proc(5) to get the executable):

 /// return a heap allocated string describing the ABI of current executable
 //// I don't recommend using this
 const char*getmyabi(void) {
   char mycmdname[80];
   int sz = snprintf(mycmdname, sizeof(mycmdname), 
                     "/usr/bin/file -L /proc/%d/exe",
                     getpid());
   assert (sz < (int) sizeof(mycmdname));
   FILE*f = popen(mycmdname, "r");
   if (!f) { 
      perror(mycmdname); exit(EXIT_FAILURE);
   };
   char* restr = NULL;
   size_t siz = 0;
   getline(&restr, &siz, f);
   if (pclose(f)) { perror("pclose"); exit(EXIT_FAILURE); };
   return restr;
 } // end of getmyabi
 /// the code above in untested

You could get a string like:

 "ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked,"
 " interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32,"
 "BuildID[sha1]=deca50aa4d3df4d57bacc464aa1e8790449ebf8e, stripped"

then you need to parse that. You could also want to parse the output of ldd(1) or of objdump(1) on your executable, your ELF interpreter ld-linux(8), etc.... (or use some ELF parsing library for that).

I don't know how useful is that getmyabi function. I don't know what precise output is file giving (in all weird cases of various ABIs). I leave you to test it (be sure to compile your test program with all the ABIs installed on your system, so gcc -m32, gcc -m64, gcc -mx32, etc....); if possible test that on some non x86 Linux system.

If you just need to get your ABI at build time, consider compiling some hello-world executable, then run file (and ldd) on it. Have appropriate build rules (Makefile rules) doing that and parsing the output of those file and ldd commands.

^{(I am surprised of your question; what kind of application needs to know the ABI; most software needing that are compilers...; a strong dependency on a precise ABI might be the symptom of undefined behavior.)}

Perhaps the hints given here might apply to your case (just a blind guess).

If you are writing some compiler, consider generating some C code in it then use some existing C compiler on that generated C code, or use a good JIT compilation library like LIBGCCJIT or LLVM. They would take care of the ABI specific aspects (and more importantly of low-level optimizations and code generation).

If you are writing a compiler alone and don't want to use external tools, you should in practice restrict yourself to one or a few ABIs and platforms. Life is short.

PS. I am not sure at all that ABI has a precise meaning. It is more a specification document than a defined feature of some system (or some executable). IIUC, the ABI specification did evolve (probably was not exactly the same 15 years ago).