So linking by ordinal only will help you a little. rebinding and
rebasing your .dll's will help much much more.
.. which has to be analysed. Has anyone a working bind app ?
One could be found at
http://www.geocities.com/shewitt_au/speedload_files/speedload.html
Ralf
One could be found at
http://www.geocities.com/shewitt_au/speedload_files/speedload.html
I have tried to rebind ld created apps and applications with this and a self
written rebind app and got a problem.
rebind does only patch the first IAT entry, if the dll is created with ld. The
others
===
- Original Message -
From: Ralf Habacker [EMAIL PROTECTED]
To: Robert Collins [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; Binutils [EMAIL PROTECTED];
Cygwin-Apps [EMAIL PROTECTED]
Sent: Tuesday, April 30, 2002 12:00 AM
Subject: RE: ordinal linking for cygwin ld
One could be found
a self
written rebind app and got a problem.
rebind does only patch the first IAT entry, if the dll is created with
ld. The
others are set to zero
Rebinding for example the cygwin1.dll to some natvie windows apps
works, so this
seems to be an ld incompatiblity.
Does
Ok, I see what it does. Doesn't it have to do that for each reference to
the auto-imported variable?
For each auto-imported variable an IMAGE_IMPORT_DESCRIPTOR and an
IMPORT_THUNK_DATA element is necessary.
If so, then heavy use of an imported variable could make the
INT and IAT quite large
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.
But as I stated already, this needs an ld switch to enable/disable ordinal
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
-Original Message-
From: Ralf Habacker [mailto:[EMAIL PROTECTED]]
Sent: Saturday, April 27, 2002 10:17 PM
To: Robert Collins; Charles Wilson
Cc: Kde-Cygwin; Binutils; Cygwin-Apps
Subject: RE: ordinal linking for cygwin ld
A patch to use hint ordinals when linking by name
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.
But as I stated already, this needs an ld switch to
-Original Message-
From: Ralf Habacker [mailto:[EMAIL PROTECTED]]
Sent: Sunday, April 28, 2002 4:28 AM
Hangon, lets go back a bit. Why do you want ordinal-only
linking? For
runtime or link-time performance? Or for on-disk import
library size?
Or
runtime
Hi all,
one of the biggest problems with kde 2.2.x currently is the very bad loading
time of applications and dll's, I've investigated some time to analyse this. On
this way I recognized, that runtime linking using symbol names is one of the
major time eater.
At first I have tried to estimate
1. Currently I' have a working solution for binutils 20011002 using a
specific import library create with an -out-implib-ordinal option,
which contains only ordinals and no symbols in the
IMPORT_DESCRIPTOR_BY_NAME structure. (The patches and testcase are appended)
The previous patch contains
Ralf Habacker wrote:
Any comments ?
Yes: compatibility. The problem with ordinal linking is, suppose
version 1 of a DLL has the following exports:
func_one 1
func_two 2
var_one DATA 3
and you link your executable to that dll by number.
Now, the vendor releases a new version of the DLL
Martin Hollmichel wrote:
Maybe you may look to openoffice.org how do the ensure that ordinals
keep the same over some time. There's a tool named ldump (located in
project tools, modules soltools) which keep's a database to keep the
ordinals in track. Maybe this helps.
at
Charles Wilson writes:
Any comments ?
Yes: compatibility. The problem with ordinal linking is, suppose
version 1 of a DLL has the following exports:
func_one 1
func_two 2
var_one DATA 3
and you link your executable to that dll by number.
Now, the vendor releases a new version of
Ralf Habacker wrote:
I'm thinking about creating to areas, an internal and an external.
New releases of kdelibs and perhaps kdebase for example are build together. So
ordinal linking is not problem. - internal area. Any other app may
be linked by name - external area.
That would cause the
Ralf Habacker wrote:
Since your app linked by ordinal, it will break if you try to run it
with the new DLL, without re-linking.
accepted
So how does the vendor ensure that he doesn't unnecessarily break
backwards compatibility, and keep the ordinals the same? By using a def
file.
-Original Message-
From: Charles Wilson [mailto:[EMAIL PROTECTED]]
Sent: Saturday, April 27, 2002 8:55 AM
To: Ralf Habacker
Cc: Kde-Cygwin; Binutils; Cygwin-Apps
Subject: Re: ordinal linking for cygwin ld
Ralf Habacker wrote:
Since your app linked by ordinal
Ralf Habacker wrote:
Ralf Habacker wrote:
I'm thinking about creating to areas, an internal and an external.
New releases of kdelibs and perhaps kdebase for example are build together. So
ordinal linking is not problem. - internal area. Any other app may
be linked by name - external area.
Robert Collins wrote:
The PE spec (as I read it) indicates that as long as a name is included
(ie it's not link-only-by-ordinal) then ordinals can change and nothing
will break.
It's only when the only link information is the ordinal that problems
will appear.
That's what I thought,
-Original Message-
From: Charles Wilson [mailto:[EMAIL PROTECTED]]
Sent: Saturday, April 27, 2002 9:04 AM
To: Robert Collins
Cc: Ralf Habacker; Kde-Cygwin; Binutils; Cygwin-Apps
Subject: Re: ordinal linking for cygwin ld
Robert Collins wrote:
The PE spec (as I read
If you use a .def file to generate your DLL, will the auto-import stuff
get added to it? Can auto-import even work, if you're linking by
ordinal -- I thought the _nm_ hints were based on the symbol name,
no, the symbol name was build from the undef section, if a corresponding
If *you* release new compatible libs with the ordinals different from
the current libs, *my* application breaks. Or, you might get ripple
effects: what if I distribute a dll that depends on KDE's libs, and Bob
has an app that depends on my dll? Bob's app breaks because my dll is
-Original Message-
From: Ralf Habacker [mailto:[EMAIL PROTECTED]]
Sent: Saturday, April 27, 2002 10:23 AM
To: Robert Collins; Charles Wilson
Cc: Kde-Cygwin; Binutils; Cygwin-Apps
Subject: RE: ordinal linking for cygwin ld
The PE spec (as I read it) indicates that as long
The PE spec (as I read it) indicates that as long as a name is included
(ie it's not link-only-by-ordinal) then ordinals can change and nothing
will break.
It's only when the only link information is the ordinal that problems
will appear.
Or ld has a switch to explicit use ordinals (see
OTOH, if you've linked by ordinal, and then you strip symbols
-- are the
names of the imports still retained?
The symbols are removed, but in the _nm_vector the names are still retained.
Ralf
Ld rules:
1. By default ordinal linking is disabled
2. Add an ld option to enable ordinal linking.
As ordinal the hint number is used. (Could this have any unknown
side effect ??)
ordinal = hint number + 1.
How should such an option be named ?
--enable-ordinal-link ?
-Original Message-
From: Ralf Habacker [mailto:[EMAIL PROTECTED]]
Sent: Saturday, April 27, 2002 10:55 AM
Or ld has a switch to explicit use ordinals (see other mails from
me)
I don't see what such a switch gains. The hint ordinal
should provide
the same performance
28 matches
Mail list logo
