The history of calling conventions, part 3

re: The history of calling conventions, part 3

Ian Hanschen — Thu, 08 Jan 2004 15:20:00 GMT

Raymond,
Great series. Do you know the what & when as far as the 0xDCBAABCD cardinal passed in when calling wndprocs?
-Ian

re: The history of calling conventions, part 3

Raymond Chen — Thu, 08 Jan 2004 15:30:00 GMT

"More on this in a future entry."

re: The history of calling conventions, part 3

Ian Hanschen — Thu, 08 Jan 2004 15:38:00 GMT

Sorry :)
-Ian

re: The history of calling conventions, part 3

Frederik Slijkerman — Thu, 08 Jan 2004 16:09:00 GMT

Honorable mention for Borland's __fastcall convention, borrowed from Delphi, which passes the first three parameters in EAX, EDX, ECX and can be slightly more efficient.

re: The history of calling conventions, part 3

Florian — Thu, 08 Jan 2004 17:59:00 GMT

Hmmm, you said that for __cdecl the parameters are pushed from right to left and for __stdcall they are pushed from left to right. But in the diagram on MSDN the stack looks identical for both calling conventions. I assume you are right and they are wrong?

re: The history of calling conventions, part 3

Raymond Chen — Thu, 08 Jan 2004 18:21:00 GMT

D'oh, you're right. __stdcall goes right to left, just like __cdecl. I'll fix the body text.

re: The history of calling conventions, part 3

Gene Hamilton — Thu, 08 Jan 2004 20:42:00 GMT

I was stepping through some code with the debugger to take a look for myself these calling conventions in action. (using VS.NET 2002 btw) And I noticed something odd. The 'call' instruction jumpes to an address which contains a single jmp instruction, which in turn 'jmp's to the real function. This is only in the 'Debug' version, not 'Release'

I also noticed after the call instruction the address it moves to, there are other jmp instructions in surrounding memory to other functions.

Here is an example.

...
call myfunc
...

myfunc:
jmp realmyfunc

realmyfunc:
...
...
ret

My Question: What is the purpose of this jmp instruction between call and the actual function? I might be answering my own question here, but here it goes.

I know if you include __declspec(dllimport) to an imported function from a dll, the code looks something like this:

CALL DWORD PTR [0x00405030]

otherwise if you don't it generates this:

CALL 0x0040100C
•••
0x0040100C:
JMP DWORD PTR [0x00405030]

Similar to was I was seeing. I know this happens because the compiler does not know if the function is static or in a dll. So it generates code like this CALL XXXXXXXX and leaves the linker to fill in the rest.

Or is it done for another reason?

re: The history of calling conventions, part 3

Raymond Chen — Thu, 08 Jan 2004 20:52:00 GMT

You probably turned on incremental linking.

http://msdn.microsoft.com/library/en-us/vccore98/HTML/_core_.2f.incremental.asp

On of the consequences of incremental linking called out in the documentation is "May contain jump thunks to handle relocation of functions to new addresses."

If you understand what incremental linking is trying to do, the need for this becomes more obvious.

re: The history of calling conventions, part 3

Terry Denham — Thu, 08 Jan 2004 21:25:00 GMT

This may be off topic but does the virtual function table behave similarly to these jump to address and then jump to final address like the incremental linking comment above.

re: The history of calling conventions, part 3

Mr. X — Thu, 08 Jan 2004 22:13:00 GMT

Calling conventions are stupid. Any good compilers (such as GCC) won't have them, except for the mandatory 'extern "C"' construct so that C++ programs can call C functions correctly.

re: The history of calling conventions, part 3

Raymond Chen — Thu, 08 Jan 2004 22:16:00 GMT

Clearly you need a calling convention or the caller and callee could never communicate with each other. Perhaps you mean "multiple calling conventions are stupid". The hard part then is choosing the "one true" calling convention that works great for everybody.

re: The history of calling conventions, part 3

Mike Dimmick — Thu, 08 Jan 2004 22:54:00 GMT

IIRC, the virtual function table is normally implemented simply as a table of addresses. The compiled code dereferences the vptr, which is the first member of the object, to locate the vtbl, then makes an indirect call through that.

On some processors (e.g. the Itanium) the table also includes a global pointer value (2MB of module-relative data can be accessed via this pointer).

I was about to ask why x86 has three calling conventions on 32-bit desktop Windows, but I assume it's for much the same reasons as 16-bit code did (which you mentioned in part 1).

IIRC, Windows CE on x86 only ever uses __cdecl, unless you're using one of the old (Pocket PC 2000 or earlier) emulators, in which case it uses __stdcall (probably a misconfiguration when compiled...)

New and Notable 33

Sam Gentile's Blog — Fri, 09 Jan 2004 04:02:00 GMT

re: The history of calling conventions, part 3

asdf — Fri, 09 Jan 2004 01:50:00 GMT

GCC has them, what are you talking about? http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html#Function%20Attributes

Search for stdcall, cdecl, fastcall, etc.

re: The history of calling conventions, part 3

project — Fri, 09 Jan 2004 05:09:00 GMT

In "thiscall" you write that function names are decorated with information about every parameter in order to allow overloading. I think this should be also true about __cdecl functions that are not extern "C". Am I right?

re: The history of calling conventions, part 3

Raymond Chen — Fri, 09 Jan 2004 05:20:00 GMT

You're right, I confused calling convention with C++ decoration. Sorry, everybody.

Why do member functions need to be

The Old New Thing — Fri, 09 Jan 2004 18:01:00 GMT

re: The history of calling conventions, part 3

CW user — Sat, 10 Jan 2004 03:31:00 GMT

Anyone using CodeWarrior?

When I had code like this:
#define EXPORT __declspec(dllexport)
EXPORT BOOL CALLBACK EdrCenterText(...)
the function GetProcAddress would return NULL.

But call like this:
GetProcAddress (..., "_EdrCenterText@16");
worked and I could use the DLL.

And then I changed the declaration to
EXPORT BOOL __cdecl EdrCenterText (...)
and
GetProcAddress (..., "EdrCenterText")
worked as advertised.

I do not have VC to check this but it all seems odd to me!

re: The history of calling conventions, part 3

project — Sat, 10 Jan 2004 04:57:00 GMT

To make the first GetProcAddress work, you should have a .def file like this:
EXPORTS
EdrCenterText

re: The history of calling conventions, part 3

Raymond Chen — Sat, 10 Jan 2004 08:55:00 GMT

CW: The GetProcAddress issue is the subject that I alluded to in the opening paragraph of Part 2 of the calling conventions series. I'll expand on it in a future entry.

re: The history of calling conventions, part 3

WC user — Sat, 10 Jan 2004 17:01:00 GMT

I've looked back to Part 2 and now I apologise if I've had spoiled
something, Raymond.

It was just something that bothered me since last summer when
it was for the first time I looked for some DLL stuff in Petzold and
then spent whole night to force GetProcAddress() return
something.

re: The history of calling conventions, part 3

Raymond Chen — Sat, 10 Jan 2004 17:10:00 GMT

No problem. You couldn't have known. It's amusing to me that somebody guessed what I was referring to there completely by accident.

re: The history of calling conventions, part 3

Ben Combee — Mon, 12 Jan 2004 19:40:00 GMT

<blockquote>Anyone using CodeWarrior?

When I had code like this:
#define EXPORT __declspec(dllexport)
EXPORT BOOL CALLBACK EdrCenterText(...)
the function GetProcAddress would return NULL.</blockquote>

The problem is that you're not putting the "__declspec(dllexport)" on the function, but instead putting it on the type.

If you'd written

#define EXPORT __declspec(dllexport)
BOOL CALLBACK EXPORT EdrCenterText(...)

it would have been OK. I know -- I once was the x86 compiler engineer at Metrowerks, and I had my hand at implementing the declspec handling code.

re: The history of calling conventions, part 3

CW user — Mon, 12 Jan 2004 23:10:00 GMT

Seems like I could have asked if there's "Anyone here who wrote
CodeWarrior?"
Just shows how relevant Raymond's blog is.

And, no, reordering keywords didn't help. Still worked only with _ and
@16 mangling.

And as an interresting note, all this time I was casting to CALLBACK function pointer:
EXPORT BOOL __cdecl EdrCenterText (...);
typedef BOOL (CALLBACK *EdrCenterTextProcType) (...);
and then later in code:
EdrCenterTextProcType plugProc;
plugProc = (EdrCenterTextProcType) GetProcAddress (..., "EdrCenterText");

This code worked OK, even though I casted __cdecl proc to __stdcall
proc. I am not much of an expert for stack handling and calling
conventions, but I would like to know for sure if this is bad in any way.
(Windows or my app never crashed, but maybe I did't wait long
enough)

re: The history of calling conventions, part 3

Raymond Chen — Mon, 12 Jan 2004 23:59:00 GMT

You people are too fast for me. I have an entry planned for Thursday to discuss this.

re: The history of calling conventions, part 3

Raymond Chen — Tue, 13 Jan 2004 18:31:00 GMT

"does the virtual function table behave similarly to these jump to address and then jump to final address like the incremental linking comment above"

The jump-to-jump is an artifact of incremental linking and is not part of the vtable layout rules.

Calling Convention

Simply Patrick — Tue, 03 Feb 2004 21:28:00 GMT

??????,??????????? ?????????? calling convention: The history of calling conventions, part 1 The history of calling conventions, part 2 The history of calling conventions, part 3 The history of calling conventions, part 4: ia64 Why do member functions need to be...

re: The history of calling conventions, part 3

Benjamin Munayco — Thu, 27 May 2004 13:52:00 GMT

Hi,

PVCAM is an ANSI C library of camera control and data acquisition functions.
I'm trying to use PVCAM functions on my computer running under Windows XP but I didn't manage to.
The problem occures when I run the project in my CodeWarrior IDE which is the programming environment I choose in order to compile my
project.
The compiling process works well, but when I link the project that's the message I'm given back:

" Error : Undefined symbol: '__stdcall(0) pl_pvcam_init
(_pl_pvcam_init@0)'
referenced from '_main' in Acquisition.c:15
Acquisition.c line 15 "

("Acquistion.c" is my C code source)

and I get the same error for each PVCAM functions (pl_pvcam_uninit, pl_seq_exp, etc.)
I am a beginner in programming on CW 8, and I don't really know where to search the problem.
This could be due to the linker, the IDE, a confusion between libraries...
Could you help me with this topic?

Thanks.

Diagnosing a problem with calling conventions

The Old New Thing — Tue, 06 Jul 2004 17:02:00 GMT

Putting together some skills you've already learned.

The history of calling conventions

Flier's Sky — Thu, 08 Jul 2004 06:03:00 GMT

The history of calling conventions

Using the Profiling API Enter/Leave Function Hooks

Jonathan Keljo's CLR Blog — Thu, 11 Aug 2005 22:20:15 GMT

Ever since v1, corprof.idl has contained the following ominous comment above the typedefs for FunctionEnter/Leave/Tailcall....

Using the Profiling API Enter/Leave Function Hooks

Jonathan Keljo's CLR Blog — Thu, 11 Aug 2005 23:47:49 GMT

Ever since v1, corprof.idl has contained the following ominous comment above the typedefs for FunctionEnter/Leave/Tailcall....

Using the Profiling API Enter/Leave Function Hooks

Jonathan Keljo's CLR Blog — Mon, 15 Aug 2005 21:55:22 GMT

Ever since v1, corprof.idl has contained the following ominous comment above the typedefs for FunctionEnter/Leave/Tailcall....

Using the Profiling API Enter/Leave Function Hooks

Jonathan Keljo's CLR Blog — Sun, 11 Sep 2005 21:13:50 GMT

Ever since v1, corprof.idl has contained the following ominous comment above the typedefs for FunctionEnter/Leave/Tailcall....

The history of calling conventions

Anuncie Aqui! — Wed, 17 May 2006 15:44:26 GMT