[PATCH] Fix LD test FAIL: export table in executable on Cygwin

Dave Korn dave.korn.cygwin@googlemail.com
Sun Mar 15 23:06:00 GMT 2009


    Hi all,

  The testcase ld-cygwin/exe-export.exp currently fails for two reasons.

#1.  The first is that the .DEF file omits the .dll suffix from the filename
given to the LIBRARY command:

----------------------------------<snip>----------------------------------
$  cat ld/testsuite/ld-cygwin/testdll.def
LIBRARY testdll

EXPORTS
dllwrite

$
----------------------------------<snip>----------------------------------

  The 'ld' manual says this about LIBRARY command syntax:

----------------------------------<snip>----------------------------------
          The optional `LIBRARY <name>' command indicates the _internal_
          name of the output DLL. If `<name>' does not include a suffix,
          the default library suffix, `.DLL' is appended.

          When the .DEF file is used to build an application, rather
          than a library, the `NAME <name>' command should be used
          instead of `LIBRARY'. If `<name>' does not include a suffix,
          the default executable suffix, `.EXE' is appended.
----------------------------------<snip>----------------------------------

  However, in this test dlltool is used to parse the .DEF file and generate an
import library, and dlltool does not have the same behaviour.  Note that the
manual for dlltool suggests that it in fact does:

----------------------------------<snip>----------------------------------
14.1 The format of the `dlltool' `.def' file
============================================

A `.def' file contains any number of the following commands:

`NAME' NAME `[ ,' BASE `]'
     The result is going to be named NAME`.exe'.

`LIBRARY' NAME `[ ,' BASE `]'
     The result is going to be named NAME`.dll'.
----------------------------------<snip>----------------------------------

but no such code to implement this behaviour exists.  The lack of a suffix on
the actual filename in the import section of the DLL fatally confuses the
runtime loader.  Trivially fixed by copying the logic used in ld into dlltool.

#2.  Another problem is that this uniquely minimal application, unlike all
other windows executables, doesn't link kernel32.dll, because the app doesn't
import from it (or from any DLL that imports from it).  However the windows
process startup code does expect it to be there (it's usually the one source
of functions you can safely call during DllMain, for example) and this is
normally guaranteed by linking with the C runtime, which is bound to import
from it.

  As we're bypassing all the standard CRT stuff in this test, we end up with
the loader initialising the DLL, then calling NtContinue with a CONTEXT
structure that points $eip to KERNEL32!BaseProcessStartThunk - but it isn't
there!  (Don't ask me exactly how ntdll.dll has managed to get the proc
address of that function without loading it; probably something to do with the
fact that the same image sections for KnownDlls are mapped into all processes.)

  It's easy to fix this; just add an import to the testcase executable to
ensure that kernel32 does, after all, get loaded and mapped at runtime.

  Ok?

binutils/ChangeLog

	* dlltool.c (set_dll_name_from_def):  Accept new second arg that
	indicates if we are building DLL or EXE, and use it to add a
	default suffix to the output filename when none is already present.
	(def_name):  Indicate we are building an EXE when calling it.
	(def_library):  Indicate we are building a DLL when calling it.

ld/testsuite/ChangeLog

	* ld-cygwin/exe-export.exp:  Add "-lkernel32" when linking test exe.
	* ld-cygwin/testexe.c (testexe_main):  Indicate whether global_a
	was set to correct final value using error return status.
	(testexe_dummy):  Dummy function calls an import from kernel32.dll
	to ensure it is mapped into the process space at runtime.


    cheers,
      DaveK

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: ya-testsuite-fixes-2.diff
URL: <https://sourceware.org/pipermail/binutils/attachments/20090315/959d44c9/attachment.ksh>


More information about the Binutils mailing list