Mail Archives: cygwin/1996/12/09/20:29:48
Short answer: you need to fix your include file.
Long answer.
I assume you are not familiar with "__cdecl" versus "__stdcall" calling
conventions.
Otherwise, I misunderstood you and pls forgive&ignore.
The __cdecl calling convention uses the caller-pops-the-stack rule.
The __stdcall calling convention uses the callee-pops-the-stack rule.
Therefore its important to know (a) by how many bytes the stack gets
popped
in an __stdcall function and (b) that caller and callee agree on who
does what.
One solution to these issues is to use different link-time names for the
two
calling conventions. For a function signature like
int foo(int) {...}
MS and compatible compilers will create link names as follows:
_foo this is the __cdecl link name
_foo AT 4 this is the __stdcall link name
Notice that the number after the "@" is NOT a DLL ordinal as you seem to
imply,
it is just the number of bytes to pop the stack off.
The compiler is instructed to use one or the other calling convention as
follows:
int __cdecl foo(int)
int __stdcall foo(int)
What if you dont say anything ?
MS compilers can be told on the command line to use one or the other
calling convention, the default is otherwise __cdecl.
Note that for "varargs" functions (such as printf) only
caller-pops-the-stack
is possible. MS compilers will enforce this (when they see the
ellipsis).
Further info:
- VC++ generates more complicated link names that cover the whole
type signature of a method. These are called "decorated names", there
is a
utility in the CD that will "undecorate" a link name back to its C
prototype.
Needless to say, the idea here is that humans dont deal with the
resulting,
long, and impossible names...
- As far as I know, this issue is specific to the x86 architecture.
Other architectures (MIPS Alpha PPC..) only support one calling
convention.
- There are other x86 calling conventions, such as __thiscall,
__fastcall...
sandro-
>----------
>From: Josef Burger[SMTP:bolo AT cs DOT wisc DOT edu]
>Sent: Monday, December 09, 1996 9:32 AM
>To: gnu-win32 AT cygnus DOT com
>Subject: code generation and dll name resolution
>
>[ I'm using b16 ]
>
>Background: I'm compiling something that uses the winsock-2 api
>instead of winsock. I built a link library for ws2_32.dll, added
>the extra declarations for winsock2 to the headers, and tried
>to build. It compiles ok, but it fails to link.
>
>The link fails because the compiled code references names such as
>'ntohs AT 4' or 'connect AT 12' instead of 'ntohs' or 'connect'. Aha,
>I say, I must rebuild my dll link library with name AT offset style
>names. That doesn't work ... because the 'name AT offset' compiled
>by the compiler is the name AT offset for the winsock-1 dll!
>
>I though the link libraries for the dlls are supposed to isolate
>normal code from the 'offset in dll' stuff????
>
>How do I tell the *compiler* to generate plain 'name', or
>'name AT offset' for functions in the winsock-2 dll I'm trying to link
>against, INSTEAD of the the winsock-1 names AT offset???
>
>thanks!
>bolo
>-
>For help on using this list, send a message to
>"gnu-win32-request AT cygnus DOT com" with one line of text: "help".
>
-
For help on using this list, send a message to
"gnu-win32-request AT cygnus DOT com" with one line of text: "help".
- Raw text -