Mail Archives: cygwin/1997/04/06/22:30:56
Jeff Tresselt[SMTP:tresselt AT flash DOT net] wrote:
>Now, with the .def file, we can build the .a import library. This is were
>I ran into a few problems that took me a short while to figure out. Here
>is the situation, if I created the import lib with the following command:
>
> dlltool --def foo.def --dllname foo.dll --output-lib libfoo.a
>
>then compiled my program using functions in the DLL, everything would
>compile with no problems. But, when I ran the executable, it would report
>an INVALID ENTRY POINT error for the functions in the DLL.
The @.. on the function names are not actually ordinals. There is a
difference between
EXPORTS
foo AT 1
and
EXPORTS
foo @1
In the first case the @1 is actually part of the function name. This
is, as far as I know, a GNU-Win32 specific thing since it is only used
for internal linking (not for the *real* DLL imports).
GNU uses these @.. values to identify functions which use the Pascal
calling convention (or that's what it seems like anyway). The number
is the number of bytes on the stack occupied by the arguments to the
function.
Almost all Win32 API functions use the Pascal calling convention, but
the names actually exported by the DLLs are simply the function names
(no @.. symbols). But you'll note in the source .def files there are
@ symbols. For example kernel32.def starts with:
EXPORTS
AddAtomA AT 4
AddAtomW AT 4
AddConsoleAliasA AT 12
AddConsoleAliasW AT 12
By default dlltool will use the full name, including the @.., for
both the internal name (as searched for by the linker) and the
function name as exported by DLL (as searched for when the program
is loaded). Unfortunately this means your program which calls
AddAtomA will look for AddAtomA AT 4 in kernel32.dll. There is, of
course, no such export, and your program will fail to load.
The reason it didn't fail to link is that functions marked with
"__attribute__ ((stdcall))" (which is what STDCALL and WINAPI,
among others, are defined as in windows32/base.h) are marked
by the compiler as having the funny @.. stuff after their names,
so the internal name does match the name generated by dlltool
from the .def file.
[snip]
>and create the import library with this:
> dlltool -k --def foo.def --dll foo.dll --ouput-lib libfoo.a
> ^^
>The -k tells dlltool to exclude the ordinals from the import library. Now
>I don't have to exclude '__stdcall' from the function declarations. So
>everything is working..........
The -k option tells dlltool that the exported function names should not
include the @.. stuff at the end, like the Win32 API DLLs. The internally
used function names still have that stuff so that the link stage will
still work when the functions are marked with stdcall. It seems to me
that the -k option would more often be useful than not (since it doesn't
do anything special to normal C calling convention function names), so
perhaps it should be default behavior and there should be some option
for turning it off instead.
The question that remains in my mind is why removing __stdcall and
calling those functions, presumably using the wrong calling convention,
worked. Perhaps I don't understand exactly how the two calling
conventions work well enough.
Colin.
-- Colin Peters - colin AT bird DOT fu DOT is DOT saga-u DOT ac DOT jp
-- Saga University Dept. of Information Science
-- http://www.fu.is.saga-u.ac.jp/~colin/index.html
-- http://www.geocities.com/Tokyo/Towers/6162/
-
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 -