This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


> 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

Attachment: ld-auto-import-dll.patch-csw
Description: Binary data

Attachment: ld-auto-import-dll.patch-csw2.gz
Description: GNU Zip compressed data


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]