Mail Archives: cygwin/1997/09/15/08:59:41
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- AT 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 AT 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 AT mm
as though it were foo AT 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 AT cygnus DOT com" with one line of text: "help".
- Raw text -