Date: Mon, 23 Aug 2004 12:24:48 -0700 From: Marcel Moolenaar <marcel@xcllnt.net> To: Doug Rabson <dfr@nlsystems.com> Cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/lib/libc/gen tls.c Message-ID: <20040823192448.GA1074@dhcp50.pn.xcllnt.net> In-Reply-To: <200408231958.41081.dfr@nlsystems.com> References: <200408231530.i7NFU5bu082414@repoman.freebsd.org> <1093283234.16672.2.camel@builder02.qubesoft.com> <20040823181827.GA706@dhcp50.pn.xcllnt.net> <200408231958.41081.dfr@nlsystems.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Aug 23, 2004 at 07:58:41PM +0100, Doug Rabson wrote: > > > > > > This is the real fix for the static binaries segfaulting on alpha. > > > With this we could re-add the change to crt1.c which enables TLS > > > for static binaries. Given that we don't yet fully support TLS for > > > alpha in either rtld or libpthread, I don't propose to change > > > lib/csu/alpha/crt1.c again for 5.3. > > > > However, if we revert the backout of crt1.c, then we know that all > > shared executables will work the moment we fix rtld and libpthread. > > If we keep the call to _init_tls() removed from crt1.c then every > > binary linked on a 5.3 machine needs to be relinked the moment we > > do add proper TLS support. So, to minimize (future) burden I suggest > > we change crt1.c back for 5.3 as well. Otherwise this will just be > > another exception on Alpha... > > But then again, none of those static binaries are likely to include TLS > (since its currently disabled for alpha). Dynamic binaries are not > affected because when rtld gets involved, it handles the TLS > initialisation istelf - _init_tls() is only used for static binaries > and is empty for dynamic. Doh... you're right. -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040823192448.GA1074>