Mailing-List: contact cygwin-apps-help AT cygwin DOT com; run by ezmlm Sender: cygwin-apps-owner AT cygwin DOT com List-Subscribe: List-Archive: List-Post: List-Help: , 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 22:21:59 +1000 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: From: "Robert Collins" To: "Ralf Habacker" , , "Charles Wilson" Cc: "Binutils" , "Cygwin-Apps" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id g3SCM5821359 > -----Original Message----- > From: Ralf Habacker [mailto:Ralf DOT Habacker AT freenet DOT de] > Sent: Sunday, April 28, 2002 10:18 PM > Firstthunk points to 0x401064, the symbol <__fu0__var0000>, > which is the address part of the mov instruction. After run > time linking the loader has relocated this address to the > propper value. Ok, I see what it does. Doesn't it have to do that for each reference to the auto-imported variable? If so, then heavy use of an imported variable could make the INT and IAT quite large - and lots of fixups needed. However, binding could still work, as we effectively have a pointer to each address reference in the binary. Rob