Mailing-List: contact cygwin-apps-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-apps-owner AT cygwin DOT com
List-Subscribe: <mailto:cygwin-apps-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-apps/>
List-Post: <mailto:cygwin-apps AT cygwin DOT com>
List-Help: <mailto:cygwin-apps-help AT cygwin DOT com>, <http://sources.redhat.com/lists.html#faqs>
Mail-Followup-To: cygwin-apps AT cygwin DOT com
Delivered-To: mailing list cygwin-apps AT cygwin DOT com
content-class: urn:content-classes:message
Subject: RE: ordinal linking for cygwin ld
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Date: Sun, 28 Apr 2002 04:27:07 +1000
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
Message-ID: <FC169E059D1A0442A04C40F86D9BA7600C5F35@itdomain003.itdomain.net.au>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
From: "Robert Collins" <robert DOT collins AT itdomain DOT com DOT au>
To: "Ralf Habacker" <Ralf DOT Habacker AT freenet DOT de>, <kde-cygwin AT mail DOT kde DOT org>,
   "Charles Wilson" <cwilson AT ece DOT gatech DOT edu>
Cc: "Binutils" <binutils AT sources DOT redhat DOT com>,
   "Cygwin-Apps" <cygwin-apps AT cygwin DOT com>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id g3RIRCZ29463



> -----Original Message-----
> From: Ralf Habacker [mailto:Ralf DOT Habacker AT freenet DOT de] 
> Sent: Saturday, April 27, 2002 10:47 PM
> To: kde-cygwin AT mail DOT kde DOT org; Charles Wilson; Robert Collins
> Cc: Binutils; Cygwin-Apps
> Subject: RE: ordinal linking for cygwin ld
> 
> 
> > Well then, this is only half the puzzle. I can see what you 
> gain from 
> > such a patch, but as Chuck as indicated, it will cause -major- 
> > difficulties in management.
> 
> Do you have read the rules I have stated for kde ?

Yes.
 
> > We'd probably also need to ensure that strip leaves the 
> names in the 
> > IAT (I wasn't clear from your other email whether it does that or 
> > not).
> >
> Yes it does. See some parts about my auto-import documentation.

Cool.
 
> $ objdump -x client.exe
> FirstThunk (2) points to the import address table (IAT), 
> which entries are identifed by corresponding _imp_... symbols.

The IAT is an array of IMAGE_THUNK_DATA, that gets overwritten by the
physical PE header of the linked image by the win32 .exe load process.
 
> HintTab (3) point to a rva (relative virtual address = offset 
> from image start) vector pointing to IMAGE_IMPORT_BY_NAME unions.

Huh? The Hinttab->hintname array is an array of IMAGE_THUNK_DATA. 
 
> (4) shows an IMAGE_IMPORT_BY_NAME union for a named link. It 
> is identifed by the _nm_<smbol> name . In this structure the 
> symbol name string is stored independed from the regular 
> symbol name, which can be only stripped.

Hmm. the diagram above is a little misleading. The IMAGE_IMPORT_BY_NAME
struct is not a union. It's IMAGE_THUNK_DATA that is a union, and for
named imports contains that RVA of the IMAGE_IMPORT_BY_NAME struct,
which has both the ordinal and the member name. Lastly there is _no_
requirement for the INT and IAT to share IMAGE_IMPORT_BY_NAME structs,
and they definitely won't share IMAGE_THUNK_DATA elements.

> (5) shows a IMAGE_IMPORT_BY_NAME union for a ordinal link.

Again, this is wrong, it stores a IMAGE_THUNK_DATA union.
 
> No see this for an auto-imported data
> 
...

> Hope that helps

Mostly. I'm a bit rusty - it's been a while since I grokked the
auto-import stuff. I'm getting back into it at the moment. The thing
that I don't follow at the moment is the how the linker fixup places the
exported data -variable- at a fixed rva at dll load time. The IAT is
-meant- to point straight to functions after the fixup occurs, so
pointing at an address in the .dll .text segment is fine. I'll re-read
Paul's explanation when I get to looking at your patch anyway.

Cheers,
Rob