Mail Archives: cygwin-developers/1998/02/18/00:57:15
From: Sergey Okhapkin <sos AT prospect DOT com DOT ru>
Date: Wed, 18 Feb 1998 10:10:15 +0300
> 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.
When dlltool builds a library, it stores the appropriate hint number
in the .idata$6 section for each .o that it builds. The linker just
links those hints into the import table.
I assume you saw the patch I sent out earlier which fixes an apparent
off by one error in dlltool. I'm not entirely sure whether this patch
is correct, but it seems to be.
It's possible to build a Windows executable which imports symbols
using ordinals rather than names. When you set up the import table
this way, there is no name at all. I don't think that dlltool will
create libraries which work this way, though.
> 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 :-(
I have realized that I was confusing hint numbers and ordinals. The
hint numbers are not ordinals. They are indexes into the export name
table.
It's true that if you change the list of exported symbols, you must
rebuild all binaries in order to continue using the hint optimization.
However, that situation is no worse than what we have today.
If we switched to import based on the ordinal number, which I am not
recommending, then we would have to be careful to not change the
ordinal numbers when changing the DLL. This is easy enough, as
dlltool permits you to specify the ordinal number for each symbol.
> 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.
It's possible that hints differ in different version of Windows, but I
expect that ordinal numbers remain the same. I can see Windows
programs that import using ordinal numbers. I don't think MS would
break those programs with new versions of NT.
In any case, I am not and was not recommending that we change to
import using ordinal numbers. I was only recommending that we use the
hints as an optimization, which is what they are intended for.
I don't see why we shouldn't think about doing that.
> 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 :-(
I don't know what bug you are referring to. I don't understand why a
bug in g++ would affect something like this.
> 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.
Great! So we should clearly rewrite the socket functions to load the
library as needed. tcl/win/tclWinSock.c has an example of just this
sort of code if somebody wants to write a patch.
> 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.
Yes, but we don't have to look up every function statically. While
it's true that eliminating an entire library gives the best result, it
may still be advantageous to eliminate a few symbol lookups.
Ian
- Raw text -