Mail Archives: cygwin-developers/1998/02/18/00:56:16
Ian Lance Taylor wrote:
>
> The import table in an executable or DLL has an ordinal hint field.
> The Windows loader is supposed to use that first when looking up the
> symbol in the DLL export table. Comparing the hint fields I find in a
> binary linked against the cygwin DLL against the export symbol table,
> both as printed by objdump -p, I find that they don't match. The
> numbers in the hint field are not the export symbol numbers.
How ld and dlltool creates hint numbers? MS linker builds a dll and an
import library in one pass and uses current time for hint number. NT's
loader never uses ordinal numbers if hints in a dll and executable do not
match, it performs name lookups this case.
> this suggests that one way to speed up the start up time is to get the
> linker and dlltool to cooperate in whatever way is required to get the
> hint numbers right. That will at least save the time required to look
> up symbols in the cygwin DLL itself.
This will require rebuild of all binaries with new libcygwin.a after
rebuilding cygwin.dll :-(
>
> We may also be able to get the hint numbers right for the main Windows
> DLLs. It seems likely enough that Windows would use the same ordinal
> numbers for the main DLLs, so that importing by ordinal number would
> work correctly. If that is so, we should be able to make our
> libraries contain the same ordinal numbers as hints, and thus save the
> lookup time for importing symbols from the popular Windows DLLs.
We shouldn't even think about it:-( I'm sure that ordinal numbers and hints
differs in different versions of Windows. Every service pack for NT
replaces some main dlls with a new ones, with different hints.
> Looking up symbols by name only as when they are required would be
> useful in certain specific circumstances. As I see it, it would
> mainly help for the cygwin DLL itself. For example, the cygwin DLL
> imports a bunch of socket functions from wsock32.dll. Those are not
> used by programs that don't use sockets, and so the time that the
> Windows loader spends in tracking down wsock32.dll and resolving all
> the symbol references is wasted for many programs.
It's the same I wrote about some time ago! Unfortunately, the bug in g++
parcer prevents from doing this changes :-(
>
> Again, I don't know how much time would be saved by omitting this.
I tried this - just replaced winsock calls with my dummy functions, and
linked this file instead of libwsock32.a to cygwin.dll. Configure scripts
ran about 20-25% faster.
> This sort of improvement would be quite easy to implement in the case
> of sockets. There may be some other specific sets of functions which
> can be looked up in this manner. The serial port functions, for
> example, although there aren't too many such functions.
Serial port functions are imported from kernel32.dll. Cygwin uses very many
imports from this dll, and this library must be linked statically. A good
candidates for dynamic loading are wsock32.dll and user32.dll (cygwin uses
about 10 imports from this dll).
--
Sergey Okhapkin, http://www.lexa.ru/sos
Moscow, Russia
Looking for a job.
- Raw text -