Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 23 Mar 2004 10:18:46 -0800 (PST)
From:      Julian Elischer <julian@elischer.org>
To:        "David O'Brien" <obrien@freebsd.org>
Cc:        Marcel Moolenaar <marcel@xcllnt.net>
Subject:   Re: SF Bay area hackfest
Message-ID:  <Pine.BSF.4.21.0403231011470.49185-100000@InterJet.elischer.org>
In-Reply-To: <20040323161204.GA57329@dragon.nuxi.com>

next in thread | previous in thread | raw e-mail | index | archive | help


On Tue, 23 Mar 2004, David O'Brien wrote:

> On Mon, Mar 22, 2004 at 06:33:03PM -0800, Marcel Moolenaar wrote:
> > On Mon, Mar 22, 2004 at 05:18:53PM -0800, Julian Elischer wrote:
> > > 
> > > project                expressd interest
> > > ----------------------------------------------
> > > TLS/toolchain        	alfred, marcel, myself
> > 
> > A couple of things come together:
> > o  gdb upgrade
> > o  New kdb framework
> > o  TLS support + debugging
> > o  Thread debugging
>  
> I still haven't seen any plan or commitment for LTS and GDB.  Other than
> pushing me to spend my time importing a new binutils (which is broken for
> sparc64).  If I import a new binutils, you need a new GCC to take full
> advantage of it.  After GCC 3.4 is imported, what *commitments* are
> people willing to make to carry it farther?  What will that work entail?
> 
> Note that ANYONE that hacks on our GDB should have FSF paperwork on file.
> We HAVE to get out of the mess of all of our local hacks.  The reason
> ports/devel/gdb6 still isn't active is the mess of bringing our GDB 5.2
> hacks forward to GDB 6.1.  I've had a WIP for a while, but it is really
> painful because we haven't done any due diligence in getting our needs
> taken care of in stock FSF GDB.  That hasn't been able to happen to date
> because the people that made many of our GDB commits wouldn't file FSF
> paperwork. :-(
> 

With new binutils we should (*) be able, with minimal more work be able
to generate statically linked binaries using TLS.  (*) the loader needs
to set some values into symbols and the thread scheduler needs code to
allocate a segment of 'M' bytes every time it rceates a new thread and
set a pointer to it.. (it already allocates some info but it needs to
allocate 'M' bytes more) where 'M' is the statically detirmined TLS
size.

The next step would be to add code to the dynamic linker to be able to
allocate  TLS segments to modules as it loads them. The TLS spec pretty
much outlines what needs to be done..

We NEED to do this.. it is not a "may be nice" item.
TLS is becoming standard on many platforms and more and  more software
is ASSUMING it is present. (e.g. nvidia drivers).





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0403231011470.49185-100000>