Mail Archives: cygwin-developers/1998/02/18/14:01:00
From: Sergey Okhapkin <sos AT buggy DOT prospect DOT com DOT ru>
Date: Wed, 18 Feb 1998 22:15:35 +0300
Ian Lance Taylor wrote:
> Here is my current understanding, which does not contradict the
> paragraph you quote. Ordinals are indexes into the import table.
> Hints are indexes into the export name table. When the loader comes
> to a symbol, it looks at the hint, and uses it to index into the
> export name table. If the name at that position in the table is the
> symbol which it is looking for, it gets the ordinal from the
> corresponding ordinal table. If the name at the hinted position is
> not the symbol which the loader is looking for, it does a binary
> search through the export name table.
I spent a lot of time digging thru hundreds of articles on MS web site
about dll internals. My understanding is the following: ordinals are
indexes into the _export_ table.
Right, sorry, I wrote the wrong thing above.
Every import contains the ordinal number,
hint and name.
I think an entry in an import table can be either an ordinal number,
or a hint and a name. I don't think you can have all three at the
same time.
Loader compares the hints of the ordinal in the export and
import tables and performs linking if the hints are equal. If not, loader
does name-based binary search.
I don't think this is correct. There is no hint in the export table.
There is an export table, which is a list of addresses. The index
into this table is the ordinal number. There is also an export name
table, which is a sorted list of symbol names, and an export name
ordinal table which corresponds to the export name table and holds the
ordinal number for each symbol in the export name table.
I think the loader uses the hint in the import entry as an index into
the export name table. If the symbol there matches the name found in
the import entry, the loader uses the export name ordinal table to get
the ordinal number. If the symbol found using the hint does not
match, the loader does a binary search in the export name table. When
it finds the symbol, it again uses the export name ordinal table to
get the ordinal number.
I think you are thinking about something else, which I came across
yesterday. For each DLL with an import table, there is a timestamp.
The linker sets the timestamp to zero, and also creates an import
address table which is a duplicate of the regular import table. A
binder program--I think this is EXEBIN--can change the import address
table to the actual addresses in the DLL, and store the timestamp of
the DLL in the timestamp field in the import table. Then the loader
can compare the timestamp in the import table with the timestamp of
the DLL, and, if they are equal, simply use the import address table
and not bother with the regular import table at all.
I don't know how much time savings you get in practice by doing this
binding step.
Ian
- Raw text -