From owner-freebsd-arch Thu Feb 15 19:19:40 2001 Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id D0A9837B491 for ; Thu, 15 Feb 2001 19:19:33 -0800 (PST) Received: from billy-club.village.org (billy-club.village.org [10.0.0.3]) by rover.village.org (8.11.2/8.11.0) with ESMTP id f1G3JSh35302; Thu, 15 Feb 2001 20:19:28 -0700 (MST) (envelope-from imp@billy-club.village.org) Received: from billy-club.village.org (localhost [127.0.0.1]) by billy-club.village.org (8.11.1/8.8.3) with ESMTP id f1G3HqE26659; Thu, 15 Feb 2001 20:17:52 -0700 (MST) Message-Id: <200102160317.f1G3HqE26659@billy-club.village.org> To: Brian Somers Subject: Re: The whole libc thing. Cc: arch@freebsd.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> Date: Thu, 15 Feb 2001 20:17:51 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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 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