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
From: "Ralf Habacker" <Ralf DOT Habacker AT freenet DOT de>
To: <kde-cygwin AT mail DOT kde DOT org>, "Charles Wilson" <cwilson AT ece DOT gatech DOT edu>,
   "Robert Collins" <robert DOT collins AT itdomain DOT com DOT au>
Cc: "Binutils" <binutils AT sources DOT redhat DOT com>,
   "Cygwin-Apps" <cygwin-apps AT cygwin DOT com>
Subject: RE: ordinal linking for cygwin ld
Date: Sun, 28 Apr 2002 14:12:27 +0200
Message-ID: <001901c1eead$f66a0260$d36707d5@BRAMSCHE>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
In-Reply-To: <FC169E059D1A0442A04C40F86D9BA7600C5F35@itdomain003.itdomain.net.au>
Importance: Normal

> > 
> > > 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.
>  
yes
> > 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. 

yes. The entries poing to the IMAGE_IMPORT_BY_NAME. 

> > (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.

Thank for this hint. In this case I was wrong. 
 

Ralf