Re: SF Bay area hackfest

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