calling-convention

The x86-64 SysV ABI specifies, among other things, how function parameters are passed in registers (first argument in rdi , then rsi and so on), and how integer return values are passed back (in rax and then rdx for really big values). What I can't find, however, is what the high bits of parameter or return value registers should be when passing types smaller than 64-bits. For example, for the following function: void foo(unsigned x, unsigned y); ... x will be passed in rdi and y in rsi , but they are only 32-bits. Do the high 32-bits of rdi and rsi need to be zero? Intuitively, I would assume

I'm currently reading the book: "Computer Systems - A Programmers Perspective". I've found out that, on the x86-64 architecture, we are limited to 6 integral parameters which will be passed to a function in registers. The next parameters will be passed on the stack. And also, the first up-to-8 FP or vector args are passed in xmm0..7. Why not use float registers in order to store the next parameters, even when the parameters are not single/double precision variables? It would be much more efficient (as far as I understood) to store the data in registers, than to store it to memory, and then

I want to pass a lambda function pointer, which nested in a class, to the Windows API callback function. I found there is no place for me to specify the __stdcall keyword. Some people told me the compile only support __cdecl , but after I used nm command to dump the obj file, I found the compile will generate three helper function ( __stdcall , __cdecl , __fastcall ) concurrently. So my problem is, how can I specify the calling convention? Those following code are my test code. #include "stdafx.h" int _tmain(int argc, _TCHAR* argv[]) { auto func = [](){}; return 0; } 00000000 t ?<helper_func

I have had this problem with C# when I was using DotNet1.1 The problem is this. I have an unmanaged dll, which has a function which takes a function pointer (among other arguments). When I declare the DLLImport in C# code, I pass a delegate. But the delegates in C# have stdcall calling convention whereas the unmanaged function expects a cdecl function pointer. Thus my naive approach resulted in crashes. Then I found the following: http://www.codeproject.com/KB/cs/cdeclcallback.aspx Some guy wrote an excellent library that enables changing calling convention of the delegate by, as I understood,

We recently attempted to break apart some of our Visual Studio projects into libraries, and everything seemed to compile and build fine in a test project with one of the library projects as a dependency. However, attempting to run the application gave us the following nasty run-time error message: Run-Time Check Failure #0 - The value of ESP was not properly saved across a function call. This is usually a result of calling a function pointer declared with a different calling convention. We have never even specified calling conventions (__cdecl etc.) for our functions, leaving all the compiler