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 From: "Ralf Habacker" To: , "Charles Wilson" , "Robert Collins" Cc: "Binutils" , "Cygwin-Apps" Subject: RE: ordinal linking for cygwin ld Date: Sat, 27 Apr 2002 14:47:16 +0200 Message-ID: <000701c1ede9$a9274310$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: 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 ? > A patch to use hint ordinals when linking by name would be _very_ useful > though, as that would > a) give the performance benefit you are looking for > b) allow backward compatible library versioning as link-by-name does. > > 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. $ objdump -x client.exe The Import Tables (interpreted .idata section contents) vma: Hint Time Forward DLL First Table Stamp Chain Name Thunk (1) 00004000 00004068 00000000 00000000 000041a8 000040b4 |(3) |(2) | _nm_.... (4) IAT | _imp_... +------+ +------------+ +------+ | (6)----+---->| Hint 16bit |(7)<------ | +------+ | +------------+ +------+ | | | | membername |(8) +------+ +------+ | +------------+ +------+ | +------+ | _nm_... (5) +------+ | +-------------+ +------+ +---->|Ordinal 16bit|(7) +------+ +-------------+ | 0x00 0x80 | +-------------+ (1) is the IMAGE_IMPORT_DESCRIPTOR. FirstThunk (2) points to the import address table (IAT), which entries are identifed by corresponding _imp_... symbols. HintTab (3) point to a rva (relative virtual address = offset from image start) vector pointing to IMAGE_IMPORT_BY_NAME unions. (4) shows an IMAGE_IMPORT_BY_NAME union for a named link. It is identifed by the _nm_ name . In this structure the symbol name string is stored independed from the regular symbol name, which can be only stripped. (5) shows a IMAGE_IMPORT_BY_NAME union for a ordinal link. Now see the relating objdump part. The numbers 6,7,8 identify the related structure element. DLL Name: dll.dll vma: Hint/Ord Member-Name (6) (7) (8) 40f4 0 printfunc0000__1Av 410c 1 var0000 00404290 <__nm__var0000>: 404290: 01 00 404292: 76 61 404294: 72 30 404296: 30 30 404298: 30 00 No see this for an auto-imported data vma: Hint Time Forward DLL First Table Stamp Chain Name Thunk 00004000 00004068 00000000 00000000 000041a8 00001064 |(3) |(2) nm_thnk_... _nm_... (4) | +------+ +------------+ __fu0_... | (6)----+---->| Hint 16bit |(7) points directly into the text segement +------+ | +------------+ to the relating instructions address | | | | Membername |(8) +------+ | +------------+ | | _nm_... (5) | +-------------+ +---->|Ordinal 16bit|(7) +-------------+ | 0x00 0x80 | +-------------+ It's the same as above except (2) points directly into the text segement to the relating instructions address. The target is identified by the __fu0_ name. See a sample below. 0xa1 is the instruction at offset 0x401063, the address starts at 0x0401063. 401063: a1 b8 40 40 00 mov 0x4040b8,%eax ^^^^^^^^^^^ 00401064 <__fu0__var0000>: ^^ (3) HintTab is identifed by the _nm_thnk_. 004040a8 <__nm_thnk__var0000>: 4040a8: 02 00 4040aa: 00 80 00 00 00 00 Hope that helps Ralf