From:	ian AT cygnus DOT com (Ian Lance Taylor)
Subject:	Re: Optimizing memset/memcpy/strcpy/etc.
17 Feb 1998 14:46:32 -0800 :
Message-ID:	<199802172241.RAA03211.cygnus.cygwin32.developers@subrogation.cygnus.com>
References:	<EoJnnG DOT 6nn AT bbc DOT com>
Reply-To:	cygwin32-developers AT cygnus DOT com
To:	cgf AT bbc DOT com (Christopher Faylor)
Cc:	cygwin32-developers AT cygnus DOT com

   From: cgf AT bbc DOT com (Christopher Faylor)
   Date: Tue, 17 Feb 1998 22:26:04 GMT

   In article <199802171723 DOT MAA29244 AT subrogation DOT cygnus DOT com>,
   Ian Lance Taylor  <cygwin32-developers AT cygnus DOT com> 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.

   Maybe I'm missing something, this is also the case using Microsoft
   tools.  I just used 'dumpbin' to print out the table of a .exe produced
   by MSDEV.  I don't see any correspondence between the numbers.  The
   numbers produced by dumpbin seem to correspond to those produced by
   objdump.

I've now figured out that the hint numbers which appear in the import
table are not the ordinal numbers.  Instead, they are the index into
the export table of the symbol.  That is, the number which appears
under ``Ordinal'' in the output of objdump -p is actually the index
into the ``[Ordinal/Name Pointer]'' table of the DLL as printed by
objdump -p.

Actually, they seem to be off by one.  I'm trying to figure out if
that is intentional or a bug.

   Are the hints numbers provided in the .lib stubs for the libraries somehow?

Yes, that's where they come from, if I understand your question
correctly.

Ian

- Raw text -