Re: Stdcall support in binutils

["Dmitry Timoshkov" <dmitry at baikal dot ru>]

"DJ Delorie" <dj@delorie.com> wrote:

> > The project consist of a number of dynamic libraries (dlls). That
> > libraries have stdcall type functions.
> 
> Do you mean that the DLLs have stdcall type functions?

Exactly.

> > I got lots of warnings despite the --enable-stdcall-fixup switch
> > (seems that --enable-stdcall-fixup and --disable-stdcall-fixup have
> > no any effect at all):
> 
> Those commands are commands for ld, not dllwrap.  It may not be
> passing them along to ld.  However, the fact that you get these
> warnings means that something else is wrong.  The stdcall suffix (the
> @4) indicates which API the function is expecting (caller pops vs
> callee pops).

Yes, I'm aware about all related things.

> If there's a mismatch, that means you're not calling
> the function right, and your program will crash eventually.  Using the
> options to disable these warnings should be done *only* if you cannot
> avoid it, which usually means you got some DLL from a third party that
> has a broken export table, and you got no import library from them
> that goes with it.

All functions are correctly prototyped as stdcall in the centralized
header files. There should not be *any* problem with caller and callee.

> > Despite the warnings above all stdcall functions from the object files are found
> > and resolved, but functions referenced from the libraries (lib2 and lib3) - not.
> 
> If library A (including import libraries for dlls, explicit or
> assumed) calls a function in library B, you must list library A before
> library B in the command line, or do something else to force library
> B's function to get added to the build.  The linker will not go
> backwards to previously scanned libraries to pull in additional
> functions.

Actually, currently I'm trying to link the only one dll which uses functions
from only one already compiled and linked library. All stdcall functions
used internally are resolved, functions from outside are not found.

> > Def files have list of exported functions without stdcall decorations:
> 
> If the functions *are* stdcall, then this is your problem.  Add the
> suffix.  It is part of the name.

But in Windows all function names exported from the standartd libraries
(kernel32, gdi32, user32, etc.) have no any suffix at all, despite the fact
that they use stdcall calling convention. I need the same effect.

> > itself leads to the decorated function names in the dll export table and
> > impossibility to run.
> 
> Why?

Because Windows' loader can not resolve them.
 
> > add a lot of complications to the building process. The real solution would
> > be to fix linker to handle stdcall names in the import libraries in the same
> > way as in the object files.
> 
> It does, but you must use the stdcall names consistently.  Using the
> cdecl names in the def file is just not going to work.  You must use
> the stdcall names in the def file *and* properly prototype all stdcall
> functions to make it work right.

As I sayed, all functions are correctly prototyped in the centralized header
files.

> > 1. dlltool does not understand the forward references in the .def files
> > (MyFunction=kernel32.FreeLibrary) when it creates an import library, but
> > dllwrap does it fine.
> 
> What about ld itself?

Haven't tryed it. Will try tomorrow.

> > 2. --add-stdcall-alias switch has no effect neither for dlltool, nor
> > for dllwrap. Import libraries, created from the .def file, have no alias
> > names without @.
> 
> That's because that option doesn't affect import libraries.  It
> affects export tables, like it says in the documentation.  The purpose
> of that option is to allow you to use GetProcAddress() without needing
> to know the stdcall suffix, nothing more.

By the way, import libraries, provided by Cygwin, have both decorated and
undecorated names of the exported functions. And in the import table of the
resulted executable there are no @ appendices at all. How they were created?

Thanks for your help.
--
Dmitry.