>
> 4014 4070 4230 40a8
>
> DLL Name: cygwin1.dll
> vma: Hint/Ord Member-Name
> 4154 26 __main 61004308
> 4160 581 calloc
> 416c 634 cygwin_internal
> 4180 652 dll_crt0
> 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 incompatiblit
===
- Original Message -
From: "Ralf Habacker" <[EMAIL PROTECTED]>
To: "Robert Collins" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; "Binutils" <[EMAIL PROTECTED]>;
"Cygwin-Apps" <[EMAIL PROTECTED]>
Sent: Tuesd
> 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
>
> > 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
> 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 la
> > Mostly. I'm a bit rusty - it's been a while since I grokked the
> > auto-import stuff. I'm getting back into it at the moment. The thing
> > that I don't follow at the moment is the how the linker fixup places the
> > exported data -variable- at a fixed rva at dll load time. The IAT is
> > -me
> -Original Message-
> From: Ralf Habacker [mailto:[EMAIL PROTECTED]]
> Sent: Sunday, April 28, 2002 10:18 PM
> Firstthunk points to 0x401064, the symbol <__fu0__var>,
> which is the address part of the mov instruction. After run
> time linking the loader has relocated this addre
> Mostly. I'm a bit rusty - it's been a while since I grokked the
> auto-import stuff. I'm getting back into it at the moment. The thing
> that I don't follow at the moment is the how the linker fixup places the
> exported data -variable- at a fixed rva at dll load time. The IAT is
> -meant- to po
> >
> > > 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
Ralf Habacker
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Robert Collins
> Sent: Saturday, April 27, 2002 8:44 PM
> To: Ralf Habacker; Charles Wilson
> Cc: Kde-Cygwin; Binutils; Cygwin-Apps
> Subject: RE: ordinal
> -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
> runt
> >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: Saturday, April 27, 2002 10:47 PM
> To: [EMAIL PROTECTED]; Charles Wilson; Robert Collins
> Cc: Binutils; Cygwin-Apps
> Subject: RE: ordinal linking for cygwin ld
>
>
> > We
> -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
> 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
> t
>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
l
> -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 s
Ralf Habacker
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Robert Collins
> Sent: Saturday, April 27, 2002 2:26 AM
> To: Ralf Habacker; Charles Wilson
> Cc: Kde-Cygwin; Binutils; Cygwin-Apps
> Subject: RE: ordinal
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
> > 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
> 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 (
> -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
>
> 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
> In the second solution I have told about, using the regular implibs and decide
> on a per case base
> if ordinal linking or not.
>
> 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 linki
> > 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
> _
> -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 wro
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 thou
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 -> externa
> -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:
>
>
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
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
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 ne
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 openoff
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
> 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 conta
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 th
37 matches
Mail list logo
