This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
RE: [Patch] skipping import libraries for performance reasons - direct auto-import of dll's
- From: "Ralf Habacker" <Ralf dot Habacker at freenet dot de>
- To: "Charles Wilson" <cwilson at ece dot gatech dot edu>
- Cc: "Binutils" <binutils at sources dot redhat dot com>,"Kde-Cygwin" <kde-cygwin at kde dot org>
- Date: Mon, 25 Nov 2002 23:50:13 +0100
- Subject: RE: [Patch] skipping import libraries for performance reasons - direct auto-import of dll's
> 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