10 Jul
2016
10 Jul
'16
1:53 p.m.
Hi Martin,
Martin Willi wrote,
Hi Waldemar,
Thanks for your answer.
You are right very diverted the code.
Better a working C implementation, then a fast and broken assembly
implementation.
See commit:
http://cgit.uclibc-ng.org/cgi/cgit/uclibc-ng.git/commit/?id=084e597e9f8e630…
best regards
Waldemar
> Has anybody else seen pthread_cond_wait()
issues on x86_64?
The test failures for x86_64 are still high:
http://tests.embedded-test.org/uClibc-
ng/1.0.15/REPORT.x86_64.libc.uClibc-ng-1.0.15
I don't see some of these test failures here locally, but instead see
failing others. But obviously there are other issues on x86_64 than the
one I've stumbled upon.
Can you compare with GNU libc
pthread_cond_wait()?
Do they use an assembler version or just C?
It seems that glibc uses the assembler variants on x86_64.
Your testcase works with GNU libc. Do you like do
find out
what is wrong in the assembly in our files? A diff shows
some differences...
The differences I could spot were mostly related to two fixes for the
priority inversion Futex code, namely glibc commits c30e8edf
and 0e3b5d6a. Not sure, but likely these are related to the issues we
see.
I would rather like to sync with GNU libc, as the
whole NPTL/TLS
stuff is mostly from there.
That certainly makes sense. All the changes glibc has seen are not
trivial, though, and unfortunately I'm not sure if I can find the time
to work on a proper patch set at this time :-/.