RE: [Patch] skipping import libraries for performance reasons - direct auto-import of dll's

["Ralf Habacker" <Ralf dot Habacker at freenet dot de>]

> Please separate policy arguments from functional arguments.  Whether
> cygwin/mingw should drop import libs is policy.  Whether libtool should
> use/create import libs is policy.  Whether ld should support auto-import
> when doing "link-directly-to-dll" is functional.
>

Okay, you mean to separate the threads. The functional things at first and if
this works then the policy.
Let's talk about the first.

> However...
>
> There does not seem to be any support in your patch for the most recent
> auto-import capabilities

It supports this stuff. This patch uses the same technice as the normal
auto-import stuff does.
It only extends the already available importing-from-dll stuff identifing and
setting data symbols.

Then it only changes the order of the below mentioned calls, so that the
auto-import stuff checks the imported-from-dll symbols too and also support the
runtime pseudo-reloc stuff.

old (ei386pe.c)
   pe_find_data_imports ();
   pe_process_import_defs(output_bfd, &link_info);

new
   pe_process_import_defs(output_bfd, &link_info);
   pe_find_data_imports ();

Se the example below:

I've added a int var2[2] array to the dll and called each element by the client
with the -Wl,-enable-runtime-pseudo-reloc option and got the following results.

(/usr/lib/gcc-lib/i686-pc-cygwin/2.95.3-5/libgcc.a)_ctors.o
Info: resolving _var by linking to __imp__var (auto-impertr000025.o(.rdata+0x0):
undefined reference to `_pei386_runtime_relocator)
Info: resolving _foo by linking to __imp__foo (auto-import)
Info: resolving _func_ptr by linking to __imp__func_ptr (auto-import)
Info: resolving _var2 by linking to __imp__var2 (auto-import)
collect2: ld returned 1 exit status
make: *** [client] Error 1

So it seems that this works.

-- the runtime-pseudo-reloc stuff added by
> Egor.  So, if your patch is accepted as-is, then we have:
>
> (1) if linking to implib, then "full" auto-import support is available;
> --enable-pseudo-reloc allows auto-import of "complex" data (see ld.info).
>
> (2) if linking directly to the dll without an implib, then "partial"
> auto-import is available; --enable-pseudo-reloc has no effect.  And
> doesn't warn that it fails.  I *think* you'd end up with a runtime
> error, if attempting to import "complex" data.
>
See above

> Bad.
>
> Two solutions:
>
> (1) add support for runtime-pseudo-relocs to your patch, and resubmit.
> You might want to work with Egor on this.

No need. See above.

>
> (2) When doing "link-directly-to-dll" AND a symbol has a non-zero addend
> (e.g. "complex" data import), then behave as if
> link_info.pei386_runtime_pseudo_reloc = 0, even if --enable-pseudo-reloc
> has been specified.  (Of course, IF --enable-pseudo-reloc has been
> specified and the current link obj is an import lib, then psuedo-reloc
> should occur).  This complex behavior may actually be more difficult --
> and more confusing -- than simply implementing solution (1).
>
> Minor nit about patch format: watch out for your tab/indentation.  It
> doesn't match the surrounding text in many cases.

Okay. How are the tab width ?

> Note: yes, I realize that the runtime-pseudo-reloc stuff requires actual
> runtime support (extra code in crt0.o for mingw, extra code in
> cygwin1.dll for cygwin) which does not yet exist.

See the above error message

Ralf