Date: Fri, 22 Apr 2005 13:57:31 -0700 From: Peter Wemm <peter@wemm.org> To: Scott Long <scottl@samsco.org> Cc: freebsd-arch@freebsd.org Subject: Re: libpthread version bump Message-ID: <200504221357.31957.peter@wemm.org> In-Reply-To: <426954D6.1080704@samsco.org> References: <Pine.GSO.4.43.0504221539580.24214-100000@sea.ntplx.net> <426954D6.1080704@samsco.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Friday 22 April 2005 12:47 pm, Scott Long wrote:
> Daniel Eischen wrote:
> > On Fri, 22 Apr 2005, Scott Long wrote:
> >>Warner Losh wrote:
> >>>>Having lived through the std{io,err,out} libc snafu, the
> >>>>libm.so.2 snafu, and now the libc.so.5/libpthread.so.1
> >>>>problem, I will once again suggest that *ALL* library
> >>>>version numbers should be bumped when a new branch is
> >>>>created.
> >>>
> >>>Yes. When a library version is bumped, *ALL* libraries that
> >>> depend on it need to be bumped. Sadly, this has proven to be too
> >>> difficult because it would create an unholy maintanence problem
> >>> for the ports.
> >>>
> >>>Warner
> >>
> >>Well, there is indeed a problem at the moment of libc being bumped
> >> for 6-current but not libpthread. However, I think that the
> >> particular problem with the fs/gs change goes above and beyond
> >> this problem. So, we have about 2 months to sort this all out.
> >> Any volunteers?
> >
> > I'm not sure I fully understand the problem, but can't you
> > just make libpthread avoid using *setbase() if the symbol
> > isn't available and use the ldt functions as a fallback?
> >
> > #pragma weak i386_get_gsbase
> > static void *have_gsbase = i386_get_gsbase;
> >
> > ...
> >
> > if (have_gsbase == NULL) {
> > /* use ldt stuff */
> > }
> > else {
> > /* use i386_get_gsbase */
> > }
> >
> > You just need something else to force the symbol i386_get_gsbase
> > to be loaded; the #pragma weak won't force it to be loaded even
> > if it is present.
>
> If that's all that it takes, then that's fine by mean. I don't
> understand the mechanics of the problem well enough to comment
> otherwise. Peter?
The only other idea that springs to mind is to use dlsym() to test for
the symbol, but that has its own serious problems. If the pragma weak
stuff works, then I'd be happy with that.
The only gotcha is that we still have to test for the possibility that
the *base syscalls return EINVAL.. This will happen for booting old
kernel.old files, and I'm not sure that current is quite robust enough
yet that people aren't going to want to be able to rewind a few months.
So, the options are:
1) test for have_gsbase using weak (or dlsym).
2) As previously suggested, add implemenations to libc.so.5 and pick
them up via a fresh compat5x. We can add an implementation to
libc.so.5. Since they wouldn't be used on 5.x, there is no risk of
breaking anything. The functions would only do something when running
the libc.so.5 library with a 5.x application on 6.x.
I have a slight preference for #2, but that would mean adding two tiny
(but otherwise unused) libc.so functions very late in the cycle. If
re@ would allow it, I'd like that. But the #pragma weak option also
works for me.
#2 can also make it a little easier to run 5.x i386 binaries on amd64 -
we could kill of most of those nasty ifdefs.
#1 would end up something like:
#pragma weak i386_set_gsbase
#pragma weak i386_get_gsbase
static void (*have_get_gsbase)(void) = i386_get_gsbase;
static void (*have_set_gsbase)(void *) = i386_set_gsbase;
if (have_i386_get_gsbase == NULL || have_get_gsbase() == -1) {
use_ldt();
} else {
use_gsbase();
}
I think that is sufficient to test if the symbols are present and test
if they work at runtime...
BTW: since somebody asked.. The runtime tests should be removed before
6.x is branched. They're only present for kernel.old compatability,
nothing else. The runtime tests are ugly.
--
Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com
"All of this is for nothing if we don't go to the stars" - JMS/B5
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200504221357.31957.peter>