So I am trying to learn about dynamic linking. On SysV ABI on amd64, functions from other shared libraries can be loaded lazily via the Procedure Linkage Table by initializing the GOT entry for the function to point at the next instruction in its plt entry. This will eventually pass control on to the dynamic linker that will load the
Tag: abi
Compiler version in C++ vs pre-compiled C libraries
I have a code that uses std=c++20. I want to use a C library that was build with old gcc version. Should I recompile the C library using the same compiler ? If no, how could you judge that the 2 ABIs are compatible? Answer There should be no problem using the library as it is. Don’t forget to add
libelf corrupts ARM elf binaries
I’m trying to manipulate ARM elf binaries on linux using the libelf library without success. Even a minimal test-case corrupts my binaries, and I don’t know why. Here is my minimal test-code which reads an elf-file and then simply writes it back: If I run this code on a ELF 64-bit x86-64 executable I get a bit-exact copy of the
Why does toolchain name have separate OS and EABI fields.?
For eg. arm-unknown-linux-gnueabi Now, once the OS i.e Linux is fixed, the C Library will be fixed (GLibc) and hence the calling convention and ABI being followed will be fixed. What is the requirement of 4th field i.e. ABI separately? Can a toolchain use a different ABI from the one used by underlying OS and LIBC. In that case how