http://sourceware.org/bugzilla/show_bug.cgi?id=15889
Bug ID: 15889
Summary: Follow microsoft convention for naming of __stdcall
function in PE-Export table
Product: binutils
Version: 2.23
Status: NEW
Severity: enhancement
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: sven.koehler at gmail dot com
When creating shared libraries (i.e. DLLs) using mingw-w64 or mingw32
toolchains, the names of functions in the PE-Export table of the DLL differs
from the naming convention that the microsoft linker follows. Consider the
following example:
Compile the source code
#define EXPORT __declspec(dllexport)
EXPORT int __cdecl fooC(int x) { return x; }
EXPORT int __stdcall fooStd(int x) { return x; }
EXPORT int __fastcall fooFast(int x) { return x; }
with the command
i686-w64-mingw32-gcc -shared -o export.dll export.c
According to i686-w64-mingw32-objdump -x export.dll, the export table looks
like this:
Export Address Table -- Ordinal Base 1
[ 0] +base[ 1] 14d2 Export RVA
[ 1] +base[ 2] 14c0 Export RVA
[ 2] +base[ 3] 14c8 Export RVA
[Ordinal/Name Pointer] Table
[ 0] @fooFast@4
[ 1] fooC
[ 2] fooStd@4
However, create a DLL from the same source with microsoft tools would yield the
following export table:
Export Address Table -- Ordinal Base 1
[ 0] +base[ 1] 14d2 Export RVA
[ 1] +base[ 2] 14c0 Export RVA
[ 2] +base[ 3] 14c8 Export RVA
[Ordinal/Name Pointer] Table
[ 0] @fooFast@4
[ 1] fooC
[ 2] _fooStd@4
The only different is the underscore, which ld removes, but microsoft linker
does not remove. The different behaviour is well known (see
http://wyw.dcweb.cn/stdcall.htm for example) and workarounds like the --kill-at
switch have been introduced. Note that the names in the export table for
__cdecl and __fastcall calling conventions are identical in both cases.
It seems that __stdcall is a calling convention frequently used when writing
DLLs. The different naming conventions in the export table cause trouble in
scenarios where a DLL but is not intended to be linked into an application
using an import lib, but is to be a "plug-in" to some other application which
uses LoadLibrary and GetProcAddress. Such may expect the names in the export
table to follow the microsoft conventions. In my case, the application is a JVM
and my DLL is a JNI library. Also, the --kill-at workaround works for me.
However, it is not clear to my why the naming-conventions have never been
adjusted to follow microsoft's design more closely. Doing so would be very
convenient to users. Thus I'd hereby like to make that request.
To the best of my knowledge this change will not effect any users that link
using import libs and should thus not have any serious side-effects.
--
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
