Well, In another set of weird “following my nose”* instances, I end reading up about cdecl calling conventions for x86.
Turns out there’s more layers involved in between the conversion of C-code to executable than the ones I was aware of.
Not only that there’s a compiler and linker stage, they are there to provide abstractions about the hardware.
Now, that’s not new, anyone who took a basic peek at Operating Systems course can tell you that.
The interesting part according to this wikipedia page
is that there’s something called an Application Binary Interface.
And then there are calling conventions. These turn out to be a set of standards agreed on by hardware manufacturers.
It turns out they needed such a thing because before microcomputers, each hardware manufacturer used to supply his own OS and compilers.
Anyway, to be specific about the cdecl, the core part or according to the wikipage the core part is,
how the caller function, callee function is translated to assembly.
And as the page says the basic idea is to push some values on to the stack by the caller function, call and once returned, clean up the stack.
caller: push ebp mov ebp, esp push 3 push 2 push 1 call callee add esp, 12 add eax, 5 pop ebp ret
Anyway, this obviously led on to one more click and read on wikipage for ABIs.
Ok, I read this page, but most of the sentences just don’t hit any connections in my brain. No wonder, I don’t have all the context or experience,
involved in working at the System internals levels. So this I won’t bother re-phrasing/summarizing.
Here’s the verbatim of Wiki page:
ABIs cover details such as:
the sizes, layout, and alignment of data types
the calling convention, which controls how functions’ arguments are passed and return values retrieved; for example, whether all parameters are passed on the stack or some are passed in registers, which registers are used for which function parameters, and whether the first function parameter passed on the stack is pushed first or last onto the stack
how an application should make system calls to the operating system and, if the ABI specifies direct system calls rather than procedure calls to system call stubs, the system call numbers
and in the case of a complete operating system ABI, the binary format of object files, program libraries and so on.
A complete ABI, such as the Intel Binary Compatibility Standard (iBCS), allows a program from one operating system supporting that ABI to run without modifications on any other such system, provided that necessary shared libraries are present, and similar prerequisites are fulfilled.
Other ABIs standardize details such as the C++ name mangling, exception propagation, and calling convention between compilers on the same platform, but do not require cross-platform compatibility.
An embedded-application binary interface (EABI) specifies standard conventions for file formats, data types, register usage, stack frame organization, and function parameter passing of an embedded software program.
The main differences of an EABI with respect to an ABI for general purpose operating systems are that privileged instructions are allowed in application code, dynamic linking is not required (sometimes it is completely disallowed), and a more compact stack frame organization is used to save memory.
* — I think the trail I followed was looking for bugs on cpython bugs page,
while came across one about ctypes module, went fishing after it, mucked around ctypes module and the examples provided there,
Ran into some error(original example was tried on windows + cygwin env), tried to figure out that problem and ended up cdecl,
while reading some blog post about ctypes usage, duh…