[Bug ld/15889] New: Follow microsoft convention for naming of __stdcall function in PE-Export table

[sven.koehler at gmail dot com]

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] @address@hidden
        [   1] fooC
        [   2] address@hidden

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] @address@hidden
        [   1] fooC
        [   2] address@hidden


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.