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

2013-08-25 Thread 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] @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


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

2013-08-25 Thread sven.koehler at gmail dot com
http://sourceware.org/bugzilla/show_bug.cgi?id=15889

Sven  changed:

   What|Removed |Added

 Target||i686-w64-mingw32
   Host||linux

-- 
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


[PATCH] runtime sysroot

2013-08-25 Thread heroxbd
Dear Guys and Gals,

When we are developing Gentoo RAP[1], a solution to run a full
independent GNU userland managed by portage in a directory prefix, we
find the feature of sysroot can be decomposed to meet a larger variaty
of needs.

The attached patch is tested against binutils-2.23 and SVN head, please
review.

Cheers,
Benda

1. http://git.heroxbd.z.tuna.tsinghua.edu.cn/?p=doc.git;a=blob;f=glep-gap.rst

===

The feature sysroot originally for cross compiling has two parts. The
first is to prepend lib path, done in configure phase, which we call
configure-time sysroot. The second is to prepend rpath in libraries
and path inside ld scripts when ld is called, which we call runtime
sysroot.

In the case of cross compilation, both are needed. While in the case
of native sysroot, which runs userland in a directory prefix natively,
only configure-time sysroot is needed.

Here we add an additional option of --enable-runtime-sysroot to fine
control such features.

2013-08-25  Benda Xu  

* configure.in: add enable-runtime-sysroot to control the 
macro ENABLE_RUNTIME_SYSROOT
* emultempl/elf32.em: only prepend rpath with sysroot when
ENABLE_RUNTIME_SYSROOT is defined
* ldfile.c: only prepend lib path with sysroot when
ENABLE_RUNTIME_SYSROOT is defined
* ld.texinfo: document this new behavior for ld script

Index: binutils-2.23/ld/configure.in
===
--- binutils-2.23.orig/ld/configure.in
+++ binutils-2.23/ld/configure.in
@@ -70,6 +70,18 @@ AC_SUBST(use_sysroot)
 AC_SUBST(TARGET_SYSTEM_ROOT)
 AC_SUBST(TARGET_SYSTEM_ROOT_DEFINE)
 
+AC_ARG_ENABLE(runtime-sysroot,
+[AS_HELP_STRING([--enable-runtime-sysroot],
+[prepend sysroot to libpath in ld script and rpath,
+ only used in addition to --with-sysroot (default is yes)])],
+[case "${enableval}" in
+  no) ;;
+  *) AC_DEFINE(ENABLE_RUNTIME_SYSROOT, [], \
+   [prepend sysroot to libpath in ld script and rpath]) ;;
+esac],
+AC_DEFINE(ENABLE_RUNTIME_SYSROOT, [], \
+  [prepend sysroot to libpath in ld script and rpath]))
+
 dnl Use --enable-gold to decide if this linker should be the default.
 dnl "install_as_default" is set to false if gold is the default linker.
 dnl "installed_linker" is the installed BFD linker name.
Index: binutils-2.23/ld/emultempl/elf32.em
===
--- binutils-2.23.orig/ld/emultempl/elf32.em
+++ binutils-2.23/ld/emultempl/elf32.em
@@ -525,7 +525,10 @@ static char *
 gld${EMULATION_NAME}_add_sysroot (const char *path)
 {
   int len, colons, i;
-  char *ret, *p;
+  char *ret;
+
+#ifdef ENABLE_RUNTIME_SYSROOT
+  char *p;
 
   len = strlen (path);
   colons = 0;
@@ -553,6 +556,11 @@ gld${EMULATION_NAME}_add_sysroot (const
   *p++ = path[i++];
 
   *p = 0;
+#else
+  ret = xmalloc (strlen (path) + 1);
+  strcpy (ret, path);
+#endif
+
   return ret;
 }
 
Index: binutils-2.23/ld/ldfile.c
===
--- binutils-2.23.orig/ld/ldfile.c
+++ binutils-2.23/ld/ldfile.c
@@ -463,7 +463,11 @@ try_open (const char *name, bfd_boolean
   result = fopen (name, "r");
 
   if (result != NULL)
+#ifdef ENABLE_RUNTIME_SYSROOT
 *sysrooted = is_sysrooted_pathname (name);
+#else
+*sysrooted = 0;
+#endif
 
   if (verbose)
 {
Index: binutils-2.23/ld/ld.texinfo
===
--- binutils-2.23.orig/ld/ld.texinfo
+++ binutils-2.23/ld/ld.texinfo
@@ -3026,13 +3026,14 @@ then you can put @samp{INPUT (subr.o)} i
 In fact, if you like, you can list all of your input files in the linker
 script, and then invoke the linker with nothing but a @samp{-T} option.
 
-In case a @dfn{sysroot prefix} is configured, and the filename starts
-with the @samp{/} character, and the script being processed was
-located inside the @dfn{sysroot prefix}, the filename will be looked
-for in the @dfn{sysroot prefix}.  Otherwise, the linker will try to
-open the file in the current directory.  If it is not found, the
-linker will search through the archive library search path.  See the
-description of @samp{-L} in @ref{Options,,Command Line Options}.
+In case a @dfn{sysroot prefix} is configured without explict
+--disable-runtime-sysroot, and the filename starts with the @samp{/}
+character, and the script being processed was located inside the
+@dfn{sysroot prefix}, the filename will be looked for in the
+@dfn{sysroot prefix}.  Otherwise, the linker will try to open the file
+in the current directory.  If it is not found, the linker will search
+through the archive library search path.  See the description of
+@samp{-L} in @ref{Options,,Command Line Options}.
 
 If you use @samp{INPUT (-l@var{file})}, @command{ld} will transform the
 name to @code{lib@var{file}.a}, as with the command line argument

___
bug-binutils mai

[Bug ld/15889] Don't remove leading underscore of __stdcall functions in PE export table

2013-08-25 Thread sven.koehler at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=15889

Sven  changed:

   What|Removed |Added

Summary|Follow microsoft convention |Don't remove leading
   |for naming of __stdcall |underscore of __stdcall
   |function in PE-Export table |functions in PE export
   ||table

-- 
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