[parisc-linux] [Update] TLS toolchain.

[parisc-linux] [Update] TLS toolchain.

[Carlos O'Donell]

Binutils is good to go with a recent merge at 2005-12-10.
GCC is working from our CVS, but the merge is 7 months old and based on
the 4.0.0 release.

GLIBC is merge from 2005-06-08 and I have tls+linuxthreads working
without many failures:
---
make[2]: *** [/glibc/math/atest-exp2.out] Error 136
make[2]: *** [/glibc/math/test-float.out] Error 136
make[2]: *** [/glibc/math/test-double.out] Error 1
make[2]: *** [/glibc/math/test-ifloat.out] Error 136
make[2]: *** [/glibc/math/test-idouble.out] Error 1
make[1]: *** [math/tests] Error 2
make[2]: *** [/glibc/linuxthreads/tst-attr1.out] Error 1
make[1]: *** [linuxthreads/tests] Error 2
make[2]: *** [/glibc/elf/tst-array1.out] Error 1
make[2]: *** [/glibc/elf/tst-array2.out] Error 1
make[2]: *** [/glibc/elf/tst-array3.out] Error 1
make[2]: *** [/glibc/elf/tst-array4.out] Error 1
make[2]: *** [/glibc/elf/tst-array1-static.out] Error 1
make[2]: *** [/glibc/elf/order.out] Error 1
make[2]: *** [/glibc/elf/nodelete2.out] Error 1
make[2]: *** [/glibc/elf/tst-align2.out] Error 1
make[2]: *** [/glibc/elf/order2.out] Error 1
make[1]: *** [elf/tests] Error 2
make: *** [check] Error 2
---
The FPU code is a bit borked right now and needs review, I tried
incorporating my changes and Daniel's alignment patch but it didn't work
out very well.

The linuxthreads tst-attr1 test is unclassified.

The elf related failures are relatively new and related to binutils.
---

I'm going to run the NPTL build and see how the tests turn out.

Anyone remember what the next step was?

Cheers,
Carlos.
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

[parisc-linux] Re: [Update] TLS toolchain.

[Randolph Chung]

> The elf related failures are relatively new and related to binutils.
> ---
> 
> I'm going to run the NPTL build and see how the tests turn out.
> 
> Anyone remember what the next step was?

I think the gcc stuff is all merged upstream already.

binutils stuff needs to be merged upstream. Perhaps we should look at
those elf related failures first.

I don't think we are ready for NPTL yet. Did we settle on how we are
implementing futexes? Are we going to implement a new kernel fsyscall
for the compare-and-exchange primitive that NPTL seems to depend on?

randolph
-- 
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

[parisc-linux] Re: [Update] TLS toolchain.

[John David Anglin]

> I don't think we are ready for NPTL yet. Did we settle on how we are
> implementing futexes? Are we going to implement a new kernel fsyscall
> for the compare-and-exchange primitive that NPTL seems to depend on?

Regarding atomic, I suggest looking at
http://www.hpl.hp.com/research/linux/atomic_ops and
http://www.hpl.hp.com/techreports/2005/HPL-2005-217.html.

I haven't had a chance to look at it but this work is part of a study
being done to add thread support to C++.  This came up when I added a
userspace implementation of CAS to java.  Apparently, gc7alpha versions
are using this code.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] Re: [Update] TLS toolchain.

[Kyle McMartin]

On Tue, Jan 10, 2006 at 03:33:11PM +0800, Randolph Chung wrote:
> I don't think we are ready for NPTL yet. Did we settle on how we are
> implementing futexes? Are we going to implement a new kernel fsyscall
> for the compare-and-exchange primitive that NPTL seems to depend on?
>

Has any thought been given to doing this via a VDSO or something that
the kernel links in? Excuse my ignorance, but this seems like a good
way to work around kernel version dependancy using straight LWS would
result in (I believe?).

Cheers,
	Kyle
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] Re: [Update] TLS toolchain.

[Carlos O'Donell]

On Tue, Jan 10, 2006 at 03:33:11PM +0800, Randolph Chung wrote:
> > The elf related failures are relatively new and related to binutils.
> > ---
> > 
> > I'm going to run the NPTL build and see how the tests turn out.
> > 
> > Anyone remember what the next step was?
> 
> I think the gcc stuff is all merged upstream already.
> 
> binutils stuff needs to be merged upstream. Perhaps we should look at
> those elf related failures first.

The constructor ordering issues? We have some failures now, but
are they regressions? Doesn't binutils head exhibit them?
 
> I don't think we are ready for NPTL yet. Did we settle on how we are
> implementing futexes? Are we going to implement a new kernel fsyscall
> for the compare-and-exchange primitive that NPTL seems to depend on?

The options in my mind are:

(1) VDSO implements atomic_compare_and_exchange.
(2) Continue to call LWS directly.

For testing we can continue to use (2).

c.

_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux