From owner-freebsd-arch@FreeBSD.ORG Fri Apr 22 21:05:46 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 8CC0216A4D0; Fri, 22 Apr 2005 21:05:46 +0000 (GMT) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1DE7543D67; Fri, 22 Apr 2005 21:05:46 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) j3ML3xwB028240; Fri, 22 Apr 2005 17:03:59 -0400 (EDT) Date: Fri, 22 Apr 2005 17:03:59 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Peter Wemm In-Reply-To: <200504221357.31957.peter@wemm.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) 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 Reply-To: Daniel Eischen 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:05:46 -0000 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 -- DE