Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Date: Thu, 11 Jul 2002 11:27:26 +0400
From: egor duda <deo AT logos-m DOT ru>
Reply-To: egor duda <cygwin AT cygwin DOT com>
Organization: deo
X-Priority: 3 (Normal)
Message-ID: <164320736084.20020711112726@logos-m.ru>
To: Charles Wilson <cwilson AT ece DOT gatech DOT edu>
CC: cygwin AT cygwin DOT com
Subject: Re: binutils with Egor's patch [was: Re: [ANNOUNCEMENT] New package: guile-1.5.6-3]
In-Reply-To: <3D2D079C.9040705@ece.gatech.edu>
References: <87fzystrvz DOT fsf AT peder DOT flower>
 <20020710203841 DOT 2f9c1189 DOT steven DOT obrien2 AT ntlworld DOT com>
 <3D2C8F96 DOT 2050704 AT ece DOT gatech DOT edu> <20020711015808 DOT GD17469 AT redhat DOT com>
 <3D2CED4D DOT 5070903 AT ece DOT gatech DOT edu> <3D2D079C DOT 9040705 AT ece DOT gatech DOT edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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/