[Patch] skipping import libraries for performance reasons - direct auto-import of dll's
Ralf Habacker
Ralf.Habacker@freenet.de
Thu Nov 28 15:18:00 GMT 2002
> Okay, I've built and tested with this patch, and looked at the code a
> little more closely than previously. I've attached a modified version
> of Ralf's patch [but don't commit my version; wait for Ralf to regen].
>
> ---------------------------------------------------------------
>
> I've initialized the [data|bss]_[start|end] variables as:
>
This makes sense. I have forgotten this, sorry.
> ---------------------------------------------------------------
>
> At one point, Ralf uses the following
>
> /* skip unwanted symbols, which are exported in buggy auto-import
> releases */
> if (strstr(erva + name_rva,"_nm_") == 0)
>
> What's the real purpose of this? It disallows my_symbol_nm_foo, as well
> as _nm_foo or _imp_nm_foo or whatever it is that you're trying to screen
> out. Would it be better to use something like this, instead:
>
> if (strncmp(erva+name_rva,"_nm_",4) != 0)
>
> which would screen out only those symbols that *begin* with _nm_? My
> modified patch does NOT make this change, but I wonder if it should.
>
Your solutions is much better, I have applied this.
> ---------------------------------------------------------------
>
> For the most part, it works as advertised. I did run in to one problem
> though. If I create a file structure like this:
>
> /usr/local/bin/cygfoo.dll
> /usr/local/lib/libfoo.dll.a -> /usr/local/bin/cygfoo.dll
>
<snip> very usefull details
> So, we have to play games in ld/sysdep.h, and modify configure.in (and
> run autoconf and autoheader) ...but once that's done, the
> /usr/local/lib/libfoo.dll.a -> /usr/local/bin/cygfoo.dll scenario works.
>
At first I have thought if this works for mingw too, but then I saw the REALPATH
macro, which protects this.
> ---------------------------------------------------------------
>
> I've split the patch into two pieces:
> ld-auto-import-dll.patch-csw
> the main changes
updated
> ld-auto-import-dll.patch-csw2.gz
> the configure and config.in changes created by running
> autoconf and autoheader.
>
copied from your mail
Changelog copied
2002-11-28 Ralf Habacker <Ralf.Habacker@freenet.de>
Charles Wilson <cwilson@ece.gatech.edu>
* ld/config.in: regenerate
* ld/configure: regenerate
* ld/configure.in: add check for realpath function
* ld/deffile.h: add .data field to def_file_import
structure
* ld/pe-dll.c (pe_proces_import_defs): use .data
field of def_file_import structure to initialize
flag_data field of def_file_export structure
(pe_implied_import_dll): new variables exp_funcbase
and [data|bss]_[start|end]. Use DLL's internal name
to set dll_name, not filename (which may be a symlink).
Scan the sections and initialize [data|bss]_[start|end].
When scanning the export table, skip _nm_ symbols, and
mark any symbols whose rva indicates that it is in the
.bss or .data sections as data.
* ld/sysdep.h: include limits.h and sys/param.h, and
define LD_PATHMAX as appropriate. Also define REALPATH
as realpath if it exists, NULL otherwise
* ld/emultempl/pe.em (gld_${EMULATION_NAME}_after_open):
call pe_process_import_defs before pe_find_data_imports,
so that auto-import will check the virtual implib as well
as "real" implibs.
(gld_${EMULATION_NAME}_recognized_file): use REALPATH to
follow symlinks to their target; check that the target's
extension is .dll before calling pe_implied_import_dll(),
not the filename itself (which may be a symlink).
> Any comments on the revised patch? Is there a better way to handle the
> realpath()/REALPATH() thing?
>
I can't see a better way. Very good work Chuck It's like a puzzle, the single
pieces are limited (=me), but all together they will give a good image. :-)
The only thing I like to say is, that instead of using a symbolic link to the
dll, the "unix" way may be possible.
What I mean is to put the dll into the lib dir (like the .so libraries in unix,
the bin dir contains only executables) and to implement a LD_LIBRARY_PATH
environmen support into cygwin1.dll, so that the dll could be used directly. But
this is only an idea and there may be objectivies not to do so.
Ralf
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ld-auto-import-dll.patch-csw
Type: application/octet-stream
Size: 7720 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/binutils/attachments/20021128/7a18786b/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ld-auto-import-dll.patch-csw2.gz
Type: application/x-gzip
Size: 4622 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/binutils/attachments/20021128/7a18786b/attachment.bin>
More information about the Binutils
mailing list