From owner-freebsd-arch@FreeBSD.ORG Fri Apr 22 21:31:14 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 20D5616A4CE; Fri, 22 Apr 2005 21:31:14 +0000 (GMT) Received: from pittgoth.com (14.zlnp1.xdsl.nauticom.net [209.195.149.111]) by mx1.FreeBSD.org (Postfix) with ESMTP id C1E5B43D46; Fri, 22 Apr 2005 21:31:12 +0000 (GMT) (envelope-from trhodes@FreeBSD.org) Received: from mobile.pittgoth.com (ip68-230-188-82.dc.dc.cox.net [68.230.188.82]) (authenticated bits=0) by pittgoth.com (8.12.10/8.12.10) with ESMTP id j3MLVAkU067050 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 22 Apr 2005 17:31:11 -0400 (EDT) (envelope-from trhodes@FreeBSD.org) Date: Fri, 22 Apr 2005 17:30:33 -0400 From: Tom Rhodes To: Peter Wemm Message-ID: <20050422173033.33890323@mobile.pittgoth.com> In-Reply-To: <200504221429.20458.peter@wemm.org> References: <200504221429.20458.peter@wemm.org> X-Mailer: Sylpheed-Claws 1.0.1 (GTK+ 1.2.10; i386-portbld-freebsd6.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit cc: Daniel Eischen cc: peter@FreeBSD.org cc: sgk@troutmask.apl.washington.edu 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 21:31:14 -0000 On Fri, 22 Apr 2005 14:29:19 -0700 Peter Wemm wrote: > On Friday 22 April 2005 02:03 pm, Daniel Eischen wrote: > > On Fri, 22 Apr 2005, Peter Wemm wrote: > > > 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... > > > > I worked up a quick patch. It compiles, but it will be some time > > before I can try it. > > > > http://people.freebsd.org/~deischen/kse/libpthread.diffs > > I think this will work. If somebody would like to try this, I think it > would be a good thing. (rebuild libpthread.so.0, and run a 5.x > threaded binary that would normally have the undefined symbols) Hey! I have one of those! And I would like to use it. Building now! :) -- Tom Rhodes