Which x86 registers to save in C functions?
Philip
Which does it assume might have changed? In effect, I am asking if I
write a custom asm function in the C style so that it can be called
from a C program compiled with gcc, which registers must I push (then
pop at the end of the function) so that I don't mess up anything else
in the program? I know there is a list of these because I once saw it,
but can't find it anymore. Thanks!
Paul Pluzhnikov
> Which registers does gcc assume do not change after a function call?
> Which does it assume might have changed?
Google for "x86 callee saved registers gcc". The first hit for me:
http://pdos.csail.mit.edu/6.828/2004/lec/l2.html
GCC dictates how the stack is used. Contract between caller and callee on x86:
* after call instruction:
o %eip points at first instruction of function
o %esp+4 points at first argument
o %esp points at return address
* after ret instruction:
o %eip contains return address
o %esp points at arguments pushed by caller
o called function may have trashed arguments
o %eax contains return value (or trash if function is void)
o %ecx, %edx may be trashed
o %ebp, %ebx, %esi, %edi must contain contents from time of call
* Terminology:
o %eax, %ecx, %edx are "caller save" registers
o %ebp, %ebx, %esi, %edi are "callee save" registers
Cheers,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.
Philip
don't know the right words to search for.
On Aug 31, 11:30 pm, Paul Pluzhnikov <ppluzhnikov-...@gmail.com>
wrote:
Oleksandr Gavenko
http://www.agner.org/optimize/calling_conventions.pdf
Such conventions firstly propose CPU vendor and after OS developers
decide what use (may be some differ). This is a part of ABI (application
binary interface, for example see 'System V ABI').
In our work we develop cryptographic lib (Russian/Ukraine cypto
standards) and for x86_32 we use one build for Open Solaris, Windows,
Linux, FreeBSD, maked by GCC 4.3.0, because ABI for those same and we
use only ANSI C library.
Truth has added option -fomit-frame-pointer because compiler added
__alloca_probe calls, be sure that all funcs on stack alloc not greater
4 KiB, because compiler added __alloca calls, remove some type, as
_allmull _alldiv, call for 64-bit arithmetic (compiler put it in some
cases, decompiling objs we find it places and rewrote these code to omit
_allmulls). In that case obtained static lib successfully linked by MSVC
link.exe linker, SunStudio ld linker and of course GCC ld on specified
platforms.
Paul Pluzhnikov
> In our work we develop cryptographic lib (Russian/Ukraine cypto
> standards) and for x86_32 we use one build for Open Solaris, Windows,
> Linux, FreeBSD, maked by GCC 4.3.0, because ABI for those same and we
> use only ANSI C library.
You almost certainly do not use 'one build' (as in, one set of
object files) for all of these platforms, because Windows uses
extended COFF, while Solaris and Linux use ELF object file format
(not sure what FreeBSD uses).
If you *really* do, please let me know just how you achieve such
a feat.
GPS
gcc has different targets, but I'm guessing the one you want is for the
i386 ABI.
Linux and BSD follow the general SysV i386 ABI function call
sequence/rules that you can find a copy of here:
http://www.stanford.edu/class/cs140/projects/pintos/specs/sysv-abi-i386-4.pdf
The register usage starts on page 35.
System calls tend to be very different in Linux than the SysV ABI,
because sysenter is used in an inline asm macro, and the first few
arguments are passed in registers. This makes porting non-C languages a
bit more difficult at times, because it requires spilling the registers
to the stack or other memory, if they were used for the runtime.
George
Oleksandr Gavenko
> You almost certainly do not use 'one build' (as in, one set of
> object files) for all of these platforms, because Windows uses
> extended COFF, while Solaris and Linux use ELF object file format
> (not sure what FreeBSD uses).
Yes, I wrong. objdump -p wrote "file format pe-i386" on Windows .obj
files and "elf32-i386" on Linux .o files.
I also highlight incompatibility in name mangling: on Windows for cdecl
calls funcs need decorate by underline, on Linux not needed.
On Mac OS X limited may be use same build as on Linux (there are some
difference with System V ABI, for example differ conventions for use
FPU/MMX register). For details may be refer to
http://gemma.apple.com/documentation/developertools/Conceptual/LowLevelABI/LowLevelABI.pdf