Date: Fri, 16 Feb 2001 23:38:46 -0700 From: Warner Losh <imp@harmony.village.org> To: Peter Jeremy <peter.jeremy@alcatel.com.au> Cc: arch@FreeBSD.ORG Subject: Re: The whole libc thing. Message-ID: <200102170638.f1H6ckW84622@harmony.village.org> In-Reply-To: Your message of "Fri, 16 Feb 2001 16:19:48 %2B1100." <20010216161948.B70642@gsmx07.alcatel.com.au> References: <20010216161948.B70642@gsmx07.alcatel.com.au> <200102160225.f1G2PFw09227@hak.lan.Awfulhak.org> <200102160317.f1G3HqE26659@billy-club.village.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <20010216161948.B70642@gsmx07.alcatel.com.au> Peter Jeremy writes:
: I think the same approach would work on the Alpha, but the sizes are
: different - according to my calculations, FILE is 64 bytes larger
: on an Alpha - 10 pointers @ 4 bytes larger and 24 bytes of padding.
Preliminary indications are that the following patch, when MFC'd to
RELENG_3 and RELENG_4 (RELENG_2 isn't relevant since it is a.out).
They hard code the size of FILE, but for legacy branches that is OK
since the size will never change and I litterally find no other way
that would work. Once these are in place and we can build compat
libraries we can move forward with peter's patches and bump libc's
major. We can also back out the gross hack that green and I put into
bridge the gap. The enclosed patch doesn't do the backing out, just
sets the groundwork for MFC so that we can be "retroactively" forward
compatible. I also do just i386 and alpha, because those are the only
platforms we need to worry about.
This is the least gross thing I can think of to make it so we can move
away from encoding sizes into binaries and libraries. I tried every
thing else I could think of that didn't hardcode these sizes. They
all failed. If you suggest something else, I want to see code that
works, not just ideas, since I don't think there is any less gross way
of doing this. If you have just ideas, I'll not even consider them
without a working implementation to go along with the idea. Sorry to
be so blunt, but the last few nights on IRC plus past discussions has
gotten me to this point of having this high a level of requirement.
First some definitions for the following discussion. First, a library
is a shared library that's linked to a binary. A binary is what is
actually run. Recall that in elf the binary effectively controlls
which libc is used. "old" means prior to all of this. "new" means
after we commit this.
How will this work?
First, it defines __stdin, et al as aliases to elements of __sF so
they are in effect of type FILE. It places __std* in our legacy
branches. This allows for old binaries that are dynamically linked
with against libraries that have been rebuilt to work, which was the
problem with Peter's patches.
Let's look at a few examples to see what will work if we go down this
path and what will fail.
Example one. Simple old binary linked to libc.so.3. With an old
libc.so.3 installed on the system, this binary works. It references
__sF. With a new libc.so.3 (after my patches are MFC'd), it still
works because __sF hasn't changed at all. s/3/4/g and you get the
same answer.
Example two. Old binary linked to libc.so.4 and libcam.so.2 on a
current system. Before the change this works now. libcam.so.2 and
the old binary have referneces to __sF, libc.so.4 satisifies them.
After I MFC the enclosed patch and install the resulting binary on my
-current system, things still work since libcam.so.2 still has
references to __sF as does the binary. If I then reimport peter's
__std* patches[*], bump libc's major and rebuild the world (this will
also be the same thing as running it on 5.0 release, when it is
golden, btw) things still work. The binary still references __sF, so
that part of it works. libcam.so.2 now contains references to the new
__std*. the updated libc.so.4 can now satisfy those references, so it
works.
[*] and back out the hacks that green and I put in, changing the size
of FILE, but not its layout.
Case 3. I've installed a port that installs libfred.so.3 from 4.2
release. It contains __sF references. I have a binary (say barney)
that links libfred.so.3 and libc.so.4. Things work now. I rebuild
the world. Things still work because neither of the above has
changed. Now let's say I want to build wilma that depends on libfred.
When wilma is built, it will fail to run because it links against
libfred.so.3 and libc.so.5.20010220. This libc doesn't have __sF, so
it will fail at link time or run time. This is easy to fix. Just
rebuild the port tht produced libfred.so.3. A new libfred.so.3 is
installed. wilma will now run (maybe after being rebuilt). barney
will also still run because it gets all the symbols it needs
(including the new libfred.so.3).
Case 4. I install a new -current system, and build everything from
scratch. This just works.
Warner
P.S. I'm still testing this out, so issues may come up. I think it
will all just work.
Index: stdio/findfp.c
===================================================================
RCS file: /home/imp/FreeBSD/CVS/src/lib/libc/stdio/findfp.c,v
retrieving revision 1.15
diff -u -r1.15 findfp.c
--- stdio/findfp.c 2001/02/16 21:09:49 1.15
+++ stdio/findfp.c 2001/02/17 06:34:05
@@ -77,6 +77,24 @@
std(__SWR|__SNBF, STDERR_FILENO)
};
+/*
+ * The following kludge is done to ensure enough binary compatibility
+ * with future versions of libc. Or rather it allows us to work with
+ * libraries that have been built with a newer libc that defines these
+ * symbols and expects libc to provide them.
+ */
+#ifdef __i386__
+__weak_reference(__sF, __stdin);
+__weak_reference(__sF+88, __stdout);
+__weak_reference(__sF+176, __stderr);
+#endif
+
+#ifdef __alpha__
+__weak_reference(__sF, __stdin);
+__weak_reference(__sF+152, __stdout);
+__weak_reference(__sF+304, __stderr);
+#endif
+
struct glue __sglue = { &uglue, 3, __sF };
static struct glue *lastglue = &uglue;
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?200102170638.f1H6ckW84622>