RE: .def files for stdcall functions (was: linking problems with the minimalist version)

RE: .def files for stdcall functions (was: linking problems with the minimalist version)

[Colin Peters]

Lachlan Roche[SMTP:lr-gnu@www.wwi.com.au] wrote:
>I have been trying to use opengl with the minimalist version of gcc-win32.
>
>I am using SGI GL for windows, and Mark Kilgard's glut32.dll
>
>I created my link liraries link:
>impdef opengl.dll > opengl.def
>dlltool --dllname opengl.dll --def opengl.def --output-lib libopengl.a -v
>
>There were no func@NN type symbols in the .def files
>
>when linking a trivial test program, I get many errors of the form:
>gltest.o(.text+0x24):gltest.c: undefined reference to `glBegin@4'
>
>Every function I use from libglut.a libglu.a or libopengl.a gives the same
>link error.
>
>What am I doing wrong? (Something trivial, no doubt)

The problem is not something you are doing wrong, as such, nor is it linked
to Mingw32 really. The problem is that impdef does not generate (and cannot
as far as I can figure out) .def files with that all important @NN suffix
on stdcall (or PASCAL or WINAPI) functions.

If impdef did generate the 'right' function names (e.g. "glBegin@4") then
you could generate your import library using the -k option to dlltool and
everything would work.

Unfortunately there is no way, that I can see, to automatically determine
this information (what number goes after the @) from the contents of a
DLL. You must parse the header file! (Please correct me if I'm wrong...
I'd love to be wrong about this.)

(NOTE for those unfamiliar with the way GNU-Win32 does stdcall functions,
it puts an @ followed by the number of bytes taken up on the stack by the
arguments onto the end of the function name. This has nothing to do with
the syntax used in .def files to define ordinals.)

In short, there is no easy way around this problem except to add all those
@NNs by hand after looking at the header file. Argh! You could, of course,
also write a program which attempted to call all the OpenGL functions, and
then copy the numbers off the "undefined reference" linker errors.

My beef with all this is: why does GCC do it this way at all? What purpose
does the @NN serve? After all, GCC knows how to generate the correct
function call given a prototype, it *generates* the @NN, so it doesn't
need it to know what to do. I don't think any other compilers add on @NN
to the names of WINAPI functions like this. Why doesn't GCC just use the
plain function name and call it with PASCAL calling convention? Someone
please enlighten me.

Sorry about the rant...

Colin.

-- Colin Peters - Saga Univ. Dept. of Information Science
-- colin@bird.fu.is.saga-u.ac.jp - finger for PGP public key
-- http://www.fu.is.saga-u.ac.jp/~colin/index.html
-- http://www.geocities.com/Tokyo/Towers/6162/

-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: .def files for stdcall functions (was: linking problems with the minimalist version)

[Gunther Ebert]

Colin Peters wrote:
> 
> My beef with all this is: why does GCC do it this way at all? What purpose
> does the @NN serve? After all, GCC knows how to generate the correct
> function call given a prototype, it *generates* the @NN, so it doesn't
> need it to know what to do. 

I see some benefit in this naming convention. Sometimes it happens that the
compiler generates the wrong code (and as a result the wrong symbol name)
of a function. This happens when the function prototype contains parameters
which are less than 4 bytes in size. For example, if you used a function

extern int _stdcall foo(char c);

void bar()
{
   ...
   foo('a');
   ...
}

the compiler would generate (in order to call the 'foo' routine) a statement
putting a single-byte character on the stack and a call statement for the
external function '_foo@1'. No problem, if the foo function had been compiled
by gcc. If it has been compiled with MSVC (and all Windows NT or Windows 95
DLLs have been compiled with some kind of MSVC) not only one single byte 
parameter would be expected by the called function but a DWORD (MSVC does DWORD 
alignment for parameters and gcc doesn't). 
If the linkage would be successful the foo function would remove the wrong number
of bytes from the stack (remember: _stdcall convention) before it returns
which would result in an unpredictable behaviour of the program. This kind of 
problem is hard to find out.
If you have ever used the RSXNT package you would probably know this problem, because
the EMX (or on Win32 RSX) port of gcc creates plain names (without the '@nn' suffix)
also for _stdcall functions, but it doesn't align parameters (in fact, this
costed me some nights of debugging).

In other words: 

1) If there are any problems with wrong or missing prototypes for
   _stdcall functions the linker would complain with an 'unresolved external' 
   message. You will never get a program with wrong function calls.
2) In order to get all Win32 API functions working there must not be any
   function prototype containing parameters which are less than 4 bytes
   in size, even if the parameters are actually WORD or CHAR or BYTE or 
   something else. Please check your windows header files if they
   contain prototypes with WORD or CHAR parameters. Replace WORD
   or CHAR parameters by DWORD parameters.

> I don't think any other compilers add on @NN
> to the names of WINAPI functions like this. Why doesn't GCC just use the
> plain function name and call it with PASCAL calling convention? Someone
> please enlighten me.
> 

In fact, MSVC mangles _stdcall names in the same manner as Cygnus gcc does.


Gunther
-- 

Gunther Ebert
iXOS Anwendungs-Software GmbH
Angerstrasse 40-42
D-04177 Leipzig

Phone : +49 341 48503-0
Fax   : +49 341 48503-99
E-mail: mailto:gunther.ebert@ixos-leipzig.de
www   : http://www.ixos-leipzig.de
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: .def files for stdcall functions

[root]

Mr colin peters writes:
> 
> The problem is not something you are doing wrong, as such, nor is it linked
> to Mingw32 really. The problem is that impdef does not generate (and cannot
> as far as I can figure out) .def files with that all important @NN suffix
> on stdcall (or PASCAL or WINAPI) functions.

You are right here. From the dll, there is no way to know the number of
parameters passed.
> 
> 
> Unfortunately there is no way, that I can see, to automatically determine
> this information (what number goes after the @) from the contents of a
> DLL. You must parse the header file! (Please correct me if I'm wrong...
> I'd love to be wrong about this.)

There is a way:
In the lcc-win32 package, you have that nice utility 'pedump'. If you have
the import *library* (the .lib that goes with the dll) you are *saved*!!!
Do the following:

1) pedump /A mylib.lib >ww
2) Edit that file 'ww'

  You will see at the beginning of the file a list of all functions exported
  from the library WITH THE DECORATED NAMES!, i.e. functionfoo@16 for instance.
  You will have to edit that file to suit the needs of the ascii file that 
  dlltool swallows, but this is no big deal... just a matter of erasing
  unnecessary stuff.

I have specially modified pedump so that it will dump .libs, with this 
objective in mind.
 
> 
> My beef with all this is: why does GCC do it this way at all? What purpose
> does the @NN serve? After all, GCC knows how to generate the correct
> function call given a prototype, it *generates* the @NN, so it doesn't
> need it to know what to do. I don't think any other compilers add on @NN
> to the names of WINAPI functions like this. Why doesn't GCC just use the
> plain function name and call it with PASCAL calling convention? Someone
> please enlighten me.

The _stdcall calling convention means that the called function cleans up the
stack. Since the compiler knows the number of arguments the rationale behind
this is that a call to a _stdcall function would fail to link.
For instance:
	extern _stdcall GetActiveWindow(void)
and then a call of
	hwnd = GetActiveWindow();
should generate an assembly of
	call _GetActiveWindow@0
and a wrong call like
	hwnd = GetActiveWindow(HWND_DESKTOP);
should generate an assembly of
	call	_GetActiveWindow@4

Since _GetActiveWindow@4 doesn't exist, the link would fail. 

But much more important, this convention FORCES you to use the standard 
header files, since if they are NOT used, the link will fail. 
The problem is, if you do not use the header files, the compiler will 
generate a NORMAL c call:

For instance:
Without header files
	C code:    IsWindowEnabled(hwnd);
      ASM code:    push  hwnd
                   call _IsWindowEnabled
                   add $4,%esp      <<<<<<<<<<<<<<<<<<<<<< adjust the stack
With header files:
	extern _stdcall IsWindowEnabled(HWND);
        C code:    IsWindowEnabled(hwnd);
      ASM code:    push hwnd
                   call _IsWindowEnabled@4
No stack cleanup is necessary.

If you have made a mistake and not included the header file, the consequence
is that the program will NOT LINK! You are saved from hours of debugging
trying to catch where the stack goes wild...
If gcc wouldn't follow this calling convention and generate the normal names,
gdb would get more usage, right, but what a pain in the *** !!!

I think that windows did it RIGHT here. Of course to say this is not politically
correct in this group... :-)  but is my opinion anyway!

Use pedump, and be saved.
It can be found at
http://www.remcomp.com/lcc-win32

-- 
Jacob Navia	Logiciels/Informatique
41 rue Maurice Ravel			Tel 01 48.23.51.44
93430 Villetaneuse 			Fax 01 48.23.95.39
France
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

yes, why @NN?!(was :Re: .def files for stdcall functions )

[J Russell Smyth]

Colin Peters wrote:

> My beef with all this is: why does GCC do it this way at all? What
> purpose
> does the @NN serve? After all, GCC knows how to generate the correct
> function call given a prototype, it *generates* the @NN, so it doesn't
>
> need it to know what to do. I don't think any other compilers add on
> @NN
> to the names of WINAPI functions like this. Why doesn't GCC just use
> the
> plain function name and call it with PASCAL calling convention?
> Someone
> please enlighten me.

 I too have wondered about this .. as I have been attempting to create
dll's that
can be used with other languages, mainly Visual Basic, I have found this
frustrating
and annoying! to create a dll for use with VB and gcc, I must create all
functions with
the @NN and alias all of them to non-@NN names for VB!  One quickview of

ANY M$ dll shows that microsofts dll's do not contain this info, where
cygwin does,
causing great grief for other-language-programmers.

This problem is also encountered with LCC which I use extensively...

   Russ Smyth
   jrussell@voicenet.com

-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

yes, why @NN?!(was :Re: .def files for stdcall functions )

[Jon Thackray]

J. Russell Smyth writes:
 > Colin Peters wrote:
 > 
 > > My beef with all this is: why does GCC do it this way at all? What
 > > purpose
 > > does the @NN serve? After all, GCC knows how to generate the correct
 > > function call given a prototype, it *generates* the @NN, so it doesn't
 > >
 > > need it to know what to do. I don't think any other compilers add on
 > > @NN
 > > to the names of WINAPI functions like this. Why doesn't GCC just use
 > > the
 > > plain function name and call it with PASCAL calling convention?
 > > Someone
 > > please enlighten me.
 > 
 >  I too have wondered about this .. as I have been attempting to create
 > dll's that
 > can be used with other languages, mainly Visual Basic, I have found this
 > frustrating
 > and annoying! to create a dll for use with VB and gcc, I must create all
 > functions with
 > the @NN and alias all of them to non-@NN names for VB!  One quickview of
 > 
 > ANY M$ dll shows that microsofts dll's do not contain this info, where
 > cygwin does,
 > causing great grief for other-language-programmers.
 > 
 > This problem is also encountered with LCC which I use extensively...

This isn't really a GCC thing. Microsoft produced the @nn stuff to
indicate the stack usage of procedures which are called by the pascal
calling convention, since such procedures clean their own stacks
before returning (using the carefully provided ret n instruction on
the x86 architectures). Since the callee rather than the caller is
cleaning the stack, even though the callee created the stack, it is
important that they agree on how much stack should be cleaned. This is
the bit gcc is doing. Now, I suspect that the problem you have is the
dll export and import tables don't match up, because one has the @nn
stuff in it and one doesn't. This isn't a link time issue, it's a load
time issue, and apart from convention, there's no reason for the
symbols in the export tables to bear any textual relationship to the
link time names of the functions they refer to. Indeed, link time
symbols of the form _foo@nn are typically translated into load time
references of the form foo, ie a leading _ and the trailing @nn are
stripped. This can lose the safety of being sure you don't call foo@mm
as though it were foo@nn. Anyway dlltool, which creates the export and
import tables, has an option (-k) to strip the trailing @nn. You
probably need to use this somewhere.
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

yes, why @NN?!(was :Re: .def files for stdcall functions )

[Jon Thackray]

Jon Thackray writes:
 > J. Russell Smyth writes:
 >  > Colin Peters wrote:
 >  > 
 >  > > My beef with all this is: why does GCC do it this way at all? What
 >  > > purpose
 >  > > does the @NN serve? After all, GCC knows how to generate the correct
 >  > > function call given a prototype, it *generates* the @NN, so it doesn't
 >  > >
 >  > > need it to know what to do. I don't think any other compilers add on
 >  > > @NN
 >  > > to the names of WINAPI functions like this. Why doesn't GCC just use
 >  > > the
 >  > > plain function name and call it with PASCAL calling convention?
 >  > > Someone
 >  > > please enlighten me.
 >  > 
 >  >  I too have wondered about this .. as I have been attempting to create
 >  > dll's that
 >  > can be used with other languages, mainly Visual Basic, I have found this
 >  > frustrating
 >  > and annoying! to create a dll for use with VB and gcc, I must create all
 >  > functions with
 >  > the @NN and alias all of them to non-@NN names for VB!  One quickview of
 >  > 
 >  > ANY M$ dll shows that microsofts dll's do not contain this info, where
 >  > cygwin does,
 >  > causing great grief for other-language-programmers.
 >  > 
 >  > This problem is also encountered with LCC which I use extensively...
 > 
 > This isn't really a GCC thing. Microsoft produced the @nn stuff to
 > indicate the stack usage of procedures which are called by the pascal
 > calling convention, since such procedures clean their own stacks
 > before returning (using the carefully provided ret n instruction on
 > the x86 architectures). Since the callee rather than the caller is
 > cleaning the stack, even though the callee created the stack, it is

                                       caller

 > important that they agree on how much stack should be cleaned. This is
 > the bit gcc is doing. Now, I suspect that the problem you have is the
 > dll export and import tables don't match up, because one has the @nn
 > stuff in it and one doesn't. This isn't a link time issue, it's a load
 > time issue, and apart from convention, there's no reason for the
 > symbols in the export tables to bear any textual relationship to the
 > link time names of the functions they refer to. Indeed, link time
 > symbols of the form _foo@nn are typically translated into load time
 > references of the form foo, ie a leading _ and the trailing @nn are
 > stripped. This can lose the safety of being sure you don't call foo@mm
 > as though it were foo@nn. Anyway dlltool, which creates the export and
 > import tables, has an option (-k) to strip the trailing @nn. You
 > probably need to use this somewhere.
 > -
 > For help on using this list (especially unsubscribing), send a message to
 > "gnu-win32-request@cygnus.com" with one line of text: "help".
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".