Mail Archives: cygwin/2002/07/11/03:28:16
Hi!
CW> Charles Wilson wrote:
>> Christopher Faylor wrote:
>>> Should I make a "test" version of binutils available with Egor's patch?
>>>
>>> Oh wait. It needs a new version of cygwin1.dll first. I guess we have
>>> to release it as 1) cygwin and 2) binutils.
>>
>> Err, not really.
>>
>> I can test his patched binutils under stock 1.3.12-2. That is, I can
>> build a library with struct FOO_struct my_array[]. I can successfully
>> build a client that accesses my_array[3].bob, and the runtime
>> pseudo-relocation works just fine.
>>
>> As long as my client doesn't fork().
>>
>> The reason for the cygwin patches, is so that the above works after a
>> fork(), because the runtime pseudo-relocs have to be redone in the
>> child. I think.
>>
>> So, the worst that could happen if you release a patched binutils but
>> not cygwin, is that
>> 1) IF some one exercised this feature
>> 2) and they fork()
>> 3) then it will break.
>> But all existing working code will continue to work -- since with
>> existing binutils we can't even LINK code that might exercise the feature.
Absolutely right.
>> So, worst case: some new code (that currently doesn't work) might
>> continue to not work -- except right now it's a build error; it'll
>> become a runtime error (but only in fork()ed children).
>>
>> Right, Egor?
>>
>> Anyway, I think you should go ahead with a test release of binutils
>> *before* a new cygwin release.
Ok, i'll try to clarify. The plan i suppose we should follow is.
0) Wait for all legal paperwork to be done.
1) Release patched binutils.
By default they are not using pseudo-relocations, so everything
should work as before.
2) Wait for some time until dust settles.
3) Patch cygwin and mingw runtimes to add 'relocator' function.
I'll look if it's possible to move all initialization stuff to
cygwin1.dll, as Chris suggested, so crt0.o is not changed.
4) Repeat step 2. :)
5) Start to update packages which want to use this feature.
6) Repeat step 2. :)
7) Patch binutils to make --enable-runtime-pseudo-reloc default.
We can also swap steps 1 and 3, i.e. release patched cygwin and/or
mingw first. This will require a tiny patch to binutils so that ld's
linker script define __RUNTIME_PSEUDO_RELOC_LIST__ and
__RUNTIME_PSEUDO_RELOC_LIST_END__ as, say, zeroes, or any other equal
addresses. In this case call to relocator will do nothing until we
release fully-patched binutils and someone uses pseudo relocations.
Now about that fork() stuff:
My test example has 2 'branches'. First one is for testing with
updated runtimes which support pseudo relocations, and second one,
which uses "manual" relocation code by implementing relocator inside
of application code calling it in the first line of 'main()'.
Chuck is right that every instance of program which uses pseudo
relocations (including forked child) should be fixed up at startup.
Actually, one can add call to _pei386_runtime_relocator in every place
in program where fork () returns 0, and manual relocation will work
fine there. You can try this:
--- crtest.c Thu Jul 11 11:12:36 2002
+++ crtest.c.new Thu Jul 11 11:11:51 2002
@@ -50,5 +50,5 @@ main ()
&__RUNTIME_PSEUDO_RELOC_LIST_END__);
#endif
-#if defined(RUNTIME_PSEUDO_RELOC_SUPPORT) && defined(HAVE_FORK)
+#if defined(HAVE_FORK)
switch (pid = fork ())
{
@@ -57,4 +57,8 @@ main ()
break;
case 0:
+#if !defined(RUNTIME_PSEUDO_RELOC_SUPPORT)
+ _pei386_runtime_relocator (&__RUNTIME_PSEUDO_RELOC_LIST__,
+ &__RUNTIME_PSEUDO_RELOC_LIST_END__);
+#endif
printf ("child: ");
print_data ();
But adding "manual" relocator is supposed to to be done for testing
purposes only. Polluting package sources with such stuff is probably
not what we want.
Egor. mailto:deo AT logos-m DOT ru ICQ 5165414 FidoNet 2:5020/496.19
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -