Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 22 Apr 2005 18:18:29 -0400
From:      Tom Rhodes <trhodes@FreeBSD.org>
To:        freebsd-arch@FreeBSD.org
Subject:   Re: libpthread version bump
Message-ID:  <20050422181829.1e0221ce@mobile.pittgoth.com>
In-Reply-To: <20050422173033.33890323@mobile.pittgoth.com>
References:  <Pine.GSO.4.43.0504221701470.24214-100000@sea.ntplx.net> <200504221429.20458.peter@wemm.org> <20050422173033.33890323@mobile.pittgoth.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 22 Apr 2005 17:30:33 -0400
Tom Rhodes <trhodes@freebsd.org> wrote:

> On Fri, 22 Apr 2005 14:29:19 -0700
> Peter Wemm <peter@wemm.org> 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!  :)

And it works.  Yay.  Thanks Dan.

-- 
Tom Rhodes



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050422181829.1e0221ce>