Date: Tue, 23 Mar 2004 14:12:42 -0700 (MST) From: Scott Long <scottl@freebsd.org> To: Julian Elischer <julian@elischer.org> Cc: Marcel Moolenaar <marcel@xcllnt.net> Subject: Re: SF Bay area hackfest Message-ID: <20040323140429.L55727@pooker.samsco.home> In-Reply-To: <Pine.BSF.4.21.0403231011470.49185-100000@InterJet.elischer.org> References: <Pine.BSF.4.21.0403231011470.49185-100000@InterJet.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 23 Mar 2004, Julian Elischer wrote: > > > 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). > So what david is asking for (and what I've asked for in the past) is a list of tasks that need to be done, and and who is going to be responsible for each one. This is a very reasonable request, and is one that I'm going to enforce. I don't want 5.3 to go out with hap-hazard and/or unfinished TLS support. SO let me start the list, and I'll let you and others add to it. If we can't get through this step, then there is absolutely no way that we can expect to get this done for 5.3. And for the record, I would really, really like to see this done for 5.3. Task Owner Import new GCC Alexander Kavaev Import new binutils ??? Modify loader (image activator?) to understand TLS ??? Modify KSE to understand TLS ??? Modify THR to understand TLS ??? Modify C_R to understand TLS ??? Modify dynamic linker for TLS ??? What else? Is there any platform specific work to be done, outside of the toolchain? Scott
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040323140429.L55727>