This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

sparc nptl mystery resolved


I reconstructed your patch relative to master on the roland/sparc-nptl
branch.  It fails where roland/nptl works because it winds up getting the
old nptl/sysdeps/unix/sysv/linux/sem_*.c instead of sysdeps/sparc/nptl/
files.  AFAICT, this results in a one-instruction difference in
sem_*wait.o{,s}:
	-  50:  d2 0e 20 05     ldub  [ %i0 + 5 ], %o1
	+  50:  d2 46 20 04     ldsw  [ %i0 + 4 ], %o1
and a much bigger difference in sem_post.

I think at this point we'll have the roland/nptl branch merged in some time
next week.  So it doesn't seem worth trying to fix the status quo ante.
You can just do that cleanup after the merge.

Incidentally, the "sparc-specific" code is so similar to the stock code
that I'd suggest you do some refactoring so it can share most of the source
instead of duplicating it.  But I haven't looked at all the details, so
maybe it's less similar than I think.

On the roland/nptl branch there are a few nptl/ test failures in the
sparc-linux build that don't show up in the sparcv9-linux build.  I presume
those were preexisting problems and nobody was testing it or caring.
Unless those failures really didn't exist a few weeks back before my
changes perturbed anything, then you might just want to wait for the merge
and settling before debugging those.


Thanks,
Roland


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]