Re: [ANNOUNCEMENT] Updated: binutils-20021117-1
Hi! Tuesday, 19 November, 2002 Christopher Faylor [EMAIL PROTECTED] wrote: CF> I've made a new version of binutils available for download. This is CF> just a refresh from sources.redhat.com. A notable change is the CF> addition of Egor Duda's --enable-runtime-pseudo-reloc option which CF> allows almost transparent linking of dll's without the need of a def CF> file. However, this option requires functionality in the cygwin DLL CF> which is not yet present. Stay tuned. Ok, it's time to revive a discussion about implementation of pseudo-relocations in runtime. So far, there were 3 propositions: 1. Implement everything in application (in crt0.o) Benefits: Will work with any version of cygwin1.dll. All problems with lack of support from runtime are detected during application linking. (Possibly) common code with mingw. Drawbacks: Will require rebuilding application in case we'll want change something. 2. Implement everything in cygwin1.dll. In this case application is about to have an external reference to _pei386_runtime_relocator. Benefits: Easy to change relocation semantics without relinking application. Drawbacks: GUI window popping up when "new" application is loaded with "old" runtime. Lack of support is detected only at application startup. 3. Implement actual relocation in dll, and call it from crt0 via cygwin_internal(). Check dll api version and print error message if runtime is too old. Benefits: Easy to change relocation semantics without relinking application. Drawbacks: Lack of support is detected only at application startup. Question: How can one distinguish console application from GUI one? What is the best wording for the error message? My own preference list (from most preferable to least preferable) is: 1st, then 3rd, then 2nd. Comments? Egor.mailto:[EMAIL PROTECTED] ICQ 5165414 FidoNet 2:5020/496.19
Re: [ANNOUNCEMENT] Updated: binutils-20021117-1
--- egor duda <[EMAIL PROTECTED]> wrote: > Hi!
>
> Tuesday, 19 November, 2002 Christopher Faylor [EMAIL PROTECTED] wrote:
>
> CF> I've made a new version of binutils available for download. This is
> CF> just a refresh from sources.redhat.com. A notable change is the
> CF> addition of Egor Duda's --enable-runtime-pseudo-reloc option which
> CF> allows almost transparent linking of dll's without the need of a def
> CF> file. However, this option requires functionality in the cygwin DLL
> CF> which is not yet present. Stay tuned.
>
> Ok, it's time to revive a discussion about implementation of
> pseudo-relocations in runtime. So far, there were 3 propositions:
>
> 1. Implement everything in application (in crt0.o)
> Benefits: Will work with any version of cygwin1.dll. All problems with
> lack of support from runtime are detected during application linking.
> (Possibly) common code with mingw.
> Drawbacks: Will require rebuilding application in case we'll want
> change something.
>
If mingw wants it, mingw will probably have to implement as (1) in crt2.o.
{Will it need to be in mingw's dllcrt2.o, also, for dll's that auto-import from
another dll?) I'm guessing you want it as an option for -mno-cygwin.
Danny
http://www.yahoo.promo.com.au/hint/ - Yahoo! Hint Dropper
- Avoid getting hideous gifts this Christmas with Yahoo! Hint Dropper!
Re: [ANNOUNCEMENT] Updated: binutils-20021117-1
On Tue, Nov 19, 2002 at 12:06:59PM +0300, egor duda wrote: >Tuesday, 19 November, 2002 Christopher Faylor [EMAIL PROTECTED] wrote: > >CF> I've made a new version of binutils available for download. This is >CF> just a refresh from sources.redhat.com. A notable change is the >CF> addition of Egor Duda's --enable-runtime-pseudo-reloc option which >CF> allows almost transparent linking of dll's without the need of a def >CF> file. However, this option requires functionality in the cygwin DLL >CF> which is not yet present. Stay tuned. > >Ok, it's time to revive a discussion about implementation of >pseudo-relocations in runtime. So far, there were 3 propositions: Did you see my questions in cygwin-patches? I replied YA to your original patch submission last Friday. Not that any of my observations really related to your summation here, though. cgf
Re: [ANNOUNCEMENT] Updated: binutils-20021117-1
Hi! Friday, 22 November, 2002 Christopher Faylor [EMAIL PROTECTED] wrote: CF> On Tue, Nov 19, 2002 at 12:06:59PM +0300, egor duda wrote: >>Tuesday, 19 November, 2002 Christopher Faylor [EMAIL PROTECTED] wrote: >> >>CF> I've made a new version of binutils available for download. This is >>CF> just a refresh from sources.redhat.com. A notable change is the >>CF> addition of Egor Duda's --enable-runtime-pseudo-reloc option which >>CF> allows almost transparent linking of dll's without the need of a def >>CF> file. However, this option requires functionality in the cygwin DLL >>CF> which is not yet present. Stay tuned. >> >>Ok, it's time to revive a discussion about implementation of >>pseudo-relocations in runtime. So far, there were 3 propositions: CF> Did you see my questions in cygwin-patches? I replied YA to your CF> original patch submission last Friday. I'm terribly sorry, I've missed them somehow. I'll try to answer here. Chris Faylor wrote: >I can see code in dll_crt0_1 being called for handling relocs. Is it >your intent that every new DLL will have to specifically call >_pei386_runtime_relocator? The dll may have its own pseudo-relocs. When app.exe uses x1.dll which in turn uses x2.dll. Now, imagine x1.dll references some data in x2.dll with addend. That means that when linking x1.dll ld will generate pseudo-reloc, which have to be resolved when x1.dll is loaded. I suppose that dll_crt0_1 is the place to handle this, but, of course i may be wrong. >I can see that over ld-land you are generating an undefined reference for >this symbol if the --enable-runtime-pseudo-reloc switch is used. Not exactly. The reference is generated whenever --enable-runtime-pseudo-reloc switch is used _and_ at least one pseudo-reloc is generated. >Is this just to ensure that there is an error message when linking with a new >version of binutils but an older version of a dll that's being built? The idea is to produce link-time error when we build final binary and link it with runtime library. If the binary has at least one pseudo-reloc then runtime ought to have support for them. This means that either libcygwin.a or crt0.o or whatever object file placed in gcc's spec file to be linked in when final binary is built, has to export _pei386_runtime_relocator. >I was thinking that a call to this code would live in the application >but obviously that's wrong. It has to live in the DLL. You mean cygwin1.dll here, right? Or client dll application is linked with? >Wouldn't that mean that it should be added somehow to _cygwin_dll_entry >winsup/cygwin/include/cygwin/cygwin_dll.h ? It only have to be called during application (or library, in case of app.exe->x1.dll->x2.dll) initialization. I'm getting little confused now as to where this call should be placed. Actually, i was thinking there's little difference, it just have to be the code which is called at startup before main() and constructors. Egor.mailto:[EMAIL PROTECTED] ICQ 5165414 FidoNet 2:5020/496.19
Re: [ANNOUNCEMENT] Updated: binutils-20021117-1
On Mon, Nov 25, 2002 at 03:31:06PM +0300, egor duda wrote: >Chris Faylor wrote: >>I can see code in dll_crt0_1 being called for handling relocs. Is it >>your intent that every new DLL will have to specifically call >>_pei386_runtime_relocator? > >The dll may have its own pseudo-relocs. When app.exe uses x1.dll >which in turn uses x2.dll. Now, imagine x1.dll references some data in >x2.dll with addend. That means that when linking x1.dll ld will >generate pseudo-reloc, which have to be resolved when x1.dll is >loaded. I suppose that dll_crt0_1 is the place to handle this, but, of >course i may be wrong. So, the above paragraph is a "yes" then. >>I can see that over ld-land you are generating an undefined reference >>for this symbol if the --enable-runtime-pseudo-reloc switch is used. > >Not exactly. The reference is generated whenever >--enable-runtime-pseudo-reloc switch is used _and_ at least one >pseudo-reloc is generated. Ok. >>Is this just to ensure that there is an error message when linking with a new >>version of binutils but an older version of a dll that's being built? > >The idea is to produce link-time error when we build final binary and >link it with runtime library. If the binary has at least one >pseudo-reloc then runtime ought to have support for them. This means >that either libcygwin.a or crt0.o or whatever object file placed in >gcc's spec file to be linked in when final binary is built, has to >export _pei386_runtime_relocator. Ok. >>I was thinking that a call to this code would live in the application >>but obviously that's wrong. It has to live in the DLL. > >You mean cygwin1.dll here, right? Or client dll application is linked >with? I meant the application, as in the application does the fixups. But that was a thinko on my part. >>Wouldn't that mean that it should be added somehow to _cygwin_dll_entry >>winsup/cygwin/include/cygwin/cygwin_dll.h ? > >It only have to be called during application (or library, in case of > app.exe->x1.dll->x2.dll) initialization. Did you look at the cygwin_dll.h file? Are you saying that you don't think the call should go there? cgf
Re: [ANNOUNCEMENT] Updated: binutils-20021117-1
Hi! Monday, 25 November, 2002 Christopher Faylor [EMAIL PROTECTED] wrote: >>>Wouldn't that mean that it should be added somehow to _cygwin_dll_entry >>>winsup/cygwin/include/cygwin/cygwin_dll.h ? >> >>It only have to be called during application (or library, in case of >> app.exe->x1.dll->x2.dll) initialization. CF> Did you look at the cygwin_dll.h file? Are you saying that you don't CF> think the call should go there? It can go there. But if it's put there, then fixups will be performed on x1.dll's refeneces to data in x2.dll only. As far as i understand, if we put fixup code to cygwin_dll.h, then we must also add it to startup code for app.exe. It's my understanding that dll_crt0_1 is the piece of code that's activated at binary startup if the binary is linked with libcygwin.a; and it doesn't matter if binary is executable or dll. But obviously, i may be wrong here, please correct me if so. Egor.mailto:[EMAIL PROTECTED] ICQ 5165414 FidoNet 2:5020/496.19
