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>