stdcall, @s, and ld/dlltool...

stdcall, @s, and ld/dlltool...

[Matthew Brett]

Hi,

I am stuck with a linking problem, and think this may be to do with
dlltool/dllwrap.

I have a third party dll, with no source, and stdcall calling
conventions, which exports @ decorated functions, like

foo@16

I have lots of code that I cannot modify, that calls the routines in
the library.  In fact it is in Fortran, but the same problem occurs in
c, if you use the -mrtd switch to enforce stdcall calling conventions.

Here's a simple replication of the problem: I made a dll like this:

/* cdll.c */
__stdcall void dllf1 () 
{
     printf("in dllf1.\n");
     return;
}

and compiled it with:
gcc -c -o cdll.o cdll.c
dllwrap --export-all --output-def cdll.def -o cdll.dll cdll.o

This exports (pexports.exe)

LIBRARY cdll.dll
EXPORTS
dllf1@0

I can generate an input library thus:

dlltool --input-def cdll.def -l libcdll.a 

and then try and call it from a little test function:

#include <stdio.h>
void dllf1();

int main () { 
  dllf1();
  return 0;
}

gcc -c -mrtd -o usedll.o usedll.c 
gcc -o usedll.exe usedll.o libcdll.a

The last line won't link with error:

usedll.o(.text+0xc):usedll.c: undefined reference to `dllf1'

I guess this is because of the difference between the decorated and
undecorated names.  The addition of --enable-stdcall-fixup to the last
call to gcc does not remove the error.  If I edit the .def file to
give:

LIBRARY cdll.dll
EXPORTS
dllf1=dllf1@0

then I can run the program usedll.exe, but get an error telling me
that the procedure entry point dllf1 could not be located in the dll
cdll.dll.

I could solve all this by adding the __stdcall attribute to the dllf1
function definition in usedll.c, rather than using the -mrtd switch,
but a) I can't do this in g77 AFAIK, and b) I can't edit the code
anyway.

So, is there any way of linking a dll function exported as "foo@0",
from an object file that is expecting "foo", without having the code
from the dll?  Why doesn't --enable-stdcall-alias work? - it seems as
though it should from the documentation.

Sorry if I have missed something very obvious (I have that feeling...)

Many thanks,

Matthew 

Re: stdcall, @s, and ld/dlltool...

[Dmitry Timoshkov]

[-- Attachment #1: Type: text/plain, Size: 968 bytes --]

"Matthew Brett" <matthew.brett@mrc-cbu.cam.ac.uk> wrote:

> I am stuck with a linking problem, and think this may be to do with
> dlltool/dllwrap.

[skipped]

Some time ago I had a similar problem. With the help from cygwin and binutils
mailing lists, I've got the following:

I was using the following command lines to build DLLs:

dllwrap -o $(LIBRARY).dll $(OBJS) $(LIBS) -k --def $(LIBRARY).def -Wl,--kill-at,--enable-stdcall-fixup
dlltool --kill-at --input-def $(LIBRARY).def --output-lib lib$(LIBRARY).a

Then just link your object files with lib$(LIBRARY).a to produce an executable image.

Notes:
1. You have to have decorated (with @) exported names in the .def file.
2. Apply the attached patch to dlltool.c from the binutils and rebuild dlltool
(Warning: this patch was made against a rather old binutils source). Patch was
approved by DJ Delorie, but for some reason was never committed.

Please let me know whether this will help.
Good luck.

-- 
Dmitry.

[-- Attachment #2: dlltool.c.diff --]
[-- Type: application/octet-stream, Size: 402 bytes --]

--- dlltool.c	Fri May 18 11:23:52 2001
+++ dlltool.c	Fri May 18 11:24:56 2001
@@ -1865,7 +1865,7 @@
 	if (!exp->noname || show_allnames)
 	  {
 	    fprintf (f, "n%d:	%s	\"%s\"\n",
-		     exp->ordinal, ASM_TEXT, exp->name);
+		     exp->ordinal, ASM_TEXT, xlate (exp->name));
 	    if (exp->forward != 0)
 	      fprintf (f, "f%d:	%s	\"%s\"\n",
 		       exp->forward, ASM_TEXT, exp->internal_name);

Re: stdcall, @s, and ld/dlltool...

[Matthew Brett]

Dear Dmitri,

> Some time ago I had a similar problem. With the help from
cygwin and binutils
> mailing lists, I've got the following:
> 
> I was using the following command lines to build DLLs:
> 
> dllwrap -o $(LIBRARY).dll $(OBJS) $(LIBS) -k --def $(LIBRARY).def
-Wl,--kill-at,--enable-stdcall-fixup
> dlltool --kill-at --input-def $(LIBRARY).def --output-lib lib$(LIBRARY).a

Many thanks for the reply.  Suffering as I have from this problem, I had
found your messages on this list, which was why I reposted here.  I have
the painful feeling I don't understand this problem completely, but my
worry is that I can't use this solution:

> dllwrap -o $(LIBRARY).dll $(OBJS) $(LIBS) -k --def $(LIBRARY).def ...

because I do not have the source for the libraries.  It is true isn't it
that for some reason --enable-stdcall-fixup when doing final linking with
the dll library created by dlltool, does not work on this problem?  Is
this a bug?

Many thanks again - and happy Xmas!

Matthew 

Re: stdcall, @s, and ld/dlltool...

[Dmitry Timoshkov]

"Matthew Brett" <matthew.brett@mrc-cbu.cam.ac.uk> wrote:

> Many thanks for the reply.  Suffering as I have from this problem, I had
> found your messages on this list, which was why I reposted here.  I have
> the painful feeling I don't understand this problem completely, but my
> worry is that I can't use this solution:
> 
> > dllwrap -o $(LIBRARY).dll $(OBJS) $(LIBS) -k --def $(LIBRARY).def ...
> 
> because I do not have the source for the libraries.  It is true isn't it
> that for some reason --enable-stdcall-fixup when doing final linking with
> the dll library created by dlltool, does not work on this problem?  Is
> this a bug?

Oh, sorry. Didn't pay enough attention to your post. But anyway, you might
create a proper import library to link with, and in that case patched dlltool
should help you here:

dlltool --kill-at --input-def $(LIBRARY).def --output-lib lib$(LIBRARY).a

-- 
Dmitry.