Date: Thu, 15 Feb 2001 20:17:51 -0700 From: Warner Losh <imp@village.org> To: Brian Somers <brian@Awfulhak.org> Cc: arch@freebsd.org Subject: Re: The whole libc thing. Message-ID: <200102160317.f1G3HqE26659@billy-club.village.org> In-Reply-To: Your message of "Fri, 16 Feb 2001 02:25:15 GMT." <200102160225.f1G2PFw09227@hak.lan.Awfulhak.org> References: <200102160225.f1G2PFw09227@hak.lan.Awfulhak.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <200102160225.f1G2PFw09227@hak.lan.Awfulhak.org> Brian Somers writes:
: Step 5.1:
: Bump the version number on all libraries that don't contain
: a dependency on libc but contain __sF references.
Umm, that can't happen. __sF is a libc dependency by definition.
stdio lives in libc.
: Produces a list of 23 libraries (out of 54) on my laptop :-( Tell me
: if I'm wrong, but I believe these libraries contain no indication of
: what libc they want, but may be mucking about with stdio internals...
That's right. That's the problem. Actually, none of them are mucking
with the internals of libc. They just know that __sF[0] is stdin,
__sF[1] is stdout, etc. They know the size of FILE. That's bad.
However, the only way these will break is for new compiles after we
bump the libc version. Old binaries linked against them will continue
to work. Barring kernel dependencies, new libraries will continue to
work with old binaries if you update libc as I describe below.
: I think step 5 can't happen 'till we declare declare a D-day after
: which old binaries and libraries just won't work.
That's half right. We don't need to declare D-day and make things not
work. There's a solution to that.
: I also can't think of any way to soften the blow. At the end of the
: day, there are binaries out there that not only know the size of sF,
: but they also play with the internals directly. Binary support of
: this without some currently-unused-internal-changed-to-a-pointer
: kludge is unlikely AFAICT.
Programs that play with the internals of stdio are few and far between
these days. Too many different ones :-)
The problems come up when we're trying to introduce new symbols. If
we do it smartly, and give users a transition time to rebuild (say 3-6
months), then we'll be be able to make this transition mostly
seamless.
The solution to all this mess is to sit tight. I know people hate
doing that, but those people will have to cope for a while.
Here's what I propose after my patches go into the tree:
1) We introduce some assembler or other magic that will alias
__stdin to __sF[0], __stdout to __sF[1], etc being
careful to preserve the size of FILE, and the __sF array.
2) We introduce this assembler to all ELF RELENG branches.
This is just RELENG_3 and RELENG_4 and current, so it isn't
as bad as it sounds.
3) We wait a while.
4) We bump libc.so.5 to libc.so.5.20010501 or something like
that. At this stage, we make __std* ala peter's changes
and start generating binaries with __std* references.
These will work with the old and the new libc, since
the size of __sF isn't encoded into the binary. This means
that old binaries with slightly fixed old libc will
continue to work.
The reason we wait a while is to give people a chance to upgrade their
libc.so.3 and libc.so.4 libraries. If they do this, or if we have the
"fixed" libraries in compat, then the old binaries will just continue
to work.
Why you ask? Well, new libraries will have __std* in them. What is
breaking things right now is that the old binaries were linking
against libc.so.OLD which doesn't have the __std* symbols. If we add
them to the old libraries as aliases, things will work as before.
Maybe even "better" because the new shared libraries won't have __sF
encoded into them. The old binaries will still have __sF encoded into
them, but that's OK because they will be using a library that matches.
The only wrinkle in all of this is old libraries and fresh builds
after libc's version is bumped. They will break because they will
have __sF in them. We've had this sort of problem before, and can
tell people in those cases they will have to rebuild the libraries.
When they rebuild the libraries, they will be abled to be linked with
old and new libc and they won't even have to recompile their old
binaries, just the old libraries.
Warner
P.S. I think that the following assembler would work for this on
i386. Alpha might be different and the only other port to worry
about. I might have an indirection error in here somewhere.
.data
.globl __stdin
.p2align 2
.type __stdin, @object
.size __stdin,4
__stdin:
.long __sF
.globl __stdout
.p2align 2
.type __stdout, @object
.size __stdout,4
__stdout:
.long __sF+88
.globl __stderr
.p2align 2
.type __stderr, @object
.size __stderr,4
__stderr
.long __sF+176
At least that's what my test program tells me:
#include <stdio.h>
extern FILE *__stdin;
extern FILE *__stdout;
extern FILE *__stderr;
int main(int argc, char **argv)
{
printf("stdin %p %p\n", stdin, __stdin);
printf("stdout %p %p\n", stdout, __stdout);
printf("stderr %p %p\n", stderr, __stderr);
}
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?200102160317.f1G3HqE26659>