From owner-freebsd-arch@FreeBSD.ORG Fri Apr 22 20:57:43 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D564E16A4CE; Fri, 22 Apr 2005 20:57:43 +0000 (GMT) Received: from canning.wemm.org (canning.wemm.org [192.203.228.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 70DDB43D39; Fri, 22 Apr 2005 20:57:43 +0000 (GMT) (envelope-from peter@wemm.org) Received: from fw.wemm.org (canning.wemm.org [192.203.228.65]) by canning.wemm.org (Postfix) with ESMTP id 37B9C2A8F6; Fri, 22 Apr 2005 13:57:43 -0700 (PDT) (envelope-from peter@wemm.org) Received: from overcee.wemm.org (overcee.wemm.org [10.0.0.3]) by fw.wemm.org (Postfix) with ESMTP id C88D3E2B5; Fri, 22 Apr 2005 13:57:42 -0700 (PDT) (envelope-from peter@wemm.org) Received: from overcee.wemm.org (localhost [127.0.0.1]) by overcee.wemm.org (8.13.1/8.13.1) with ESMTP id j3MKvfUL072850; Fri, 22 Apr 2005 13:57:41 -0700 (PDT) (envelope-from peter@wemm.org) Received: from localhost (localhost [[UNIX: localhost]]) by overcee.wemm.org (8.13.1/8.13.1/Submit) id j3MKvWYl072849; Fri, 22 Apr 2005 13:57:32 -0700 (PDT) (envelope-from peter@wemm.org) X-Authentication-Warning: overcee.wemm.org: peter set sender to peter@wemm.org using -f From: Peter Wemm To: Scott Long Date: Fri, 22 Apr 2005 13:57:31 -0700 User-Agent: KMail/1.7.1 References: <426954D6.1080704@samsco.org> In-Reply-To: <426954D6.1080704@samsco.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200504221357.31957.peter@wemm.org> cc: Daniel Eischen cc: sgk@troutmask.apl.washington.edu cc: peter@freebsd.org cc: freebsd-arch@freebsd.org Subject: Re: libpthread version bump X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2005 20:57:44 -0000 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