This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
RE: ordinal linking for cygwin ld
- 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>
- Date: Sat, 27 Apr 2002 14:47:16 +0200
- 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 ?
> 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
<snip>
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_<smbol> 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_<symbol> 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_<symbol>.
004040a8 <__nm_thnk__var0000>:
4040a8: 02 00
4040aa: 00 80 00 00 00 00
Hope that helps
Ralf