Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 15 Feb 2001 09:04:45 -0700
From:      Warner Losh <imp@harmony.village.org>
To:        arch@FreeBSD.ORG
Subject:   Re: The whole libc thing. 
Message-ID:  <200102151604.f1FG4jW62156@harmony.village.org>
In-Reply-To: Your message of "Thu, 15 Feb 2001 02:03:53 MST." <200102150903.f1F93rW62243@harmony.village.org> 
References:  <200102150903.f1F93rW62243@harmony.village.org>  

next in thread | previous in thread | raw e-mail | index | archive | help
In message <200102150903.f1F93rW62243@harmony.village.org> Warner Losh writes:
: Green's solution of stealing a pointer and using that to "grow" FILE.
: This would allow old binaris to keep working at the cost of binary
: compatibility.  There's a few extra indirections in this case, you'll
: likely not be able to measure that performance loss.  But it will work
: with the case above and most of the others we threw at it.

I've become convinced that the old FILE layout is what we need to do.

Step 1:
	Back out to Feb 10.

Step 2:
	Apply Green's and Daniel's changes (Green to get the new
	layout, Daniel's for thread locking).  These two changes
	are in my tree right now.

Step 3:
	Introduce __stdin, __stdout, and __stderr into libc.so.3,
	libc.so.4 and libc.so.5.  WE can do this in the building of
	libc.so via a trick that Tor Egge sent me (he did it to
	libc.so.3):

--- /usr/obj/usr/src/gnu/usr.bin/binutils/ld/ldscripts/elf_i386.xs	Sun Feb  4 00:23:05 2001
+++ /tmp/tegge1	Thu Feb 15 05:46:01 2001
@@ -62,6 +62,9 @@
   .data    :
   {
     *(.data)
+    __stdin = __sF;
+    __stdout = __sF +0x58 ;
+    __stderr = __sF +0xB0 ;
     *(.gnu.linkonce.d*)
     CONSTRUCTORS
   }

	Or, alternatively, I think that we could do this with a small
	amount of assembler on each platform that we support (i386,
	pc98 and alpha).  I'm not sure how to do this, but something
	like the following might work on i386:
		.set __stdin, __sF
		.set __stdout, __sF + 0x58
		.set __stderr, __sF + 0xB0


Step 4:
	Create compat libraries for libc.so.4 and libc.so.3.
	Encourage people to upgrade to these.  This is the hard part
	and the weak part of my plan.

Step 5: <in a while, assuming that 3 and 4 work>
	Bump the major version of libc and start using something like
	peter's change.

I think that this will work.  But need to make sure that we have no
cases where newer libraries are using __sF and that breaking things.
I'll try to put together a table to convince myself and others that
this path will work.  Steps 1 and 2 are known to work.

Warner



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200102151604.f1FG4jW62156>