[NPTL] Questions about testing

Dan E trg_info at mailhaven.com
Mon Apr 20 21:41:55 UTC 2009


On Sat, 18 Apr 2009 18:20 +0200, "Carmelo Amoroso" <carmelo73 at gmail.com>
wrote:
> IIRC, on sh, tls testes pass all, only 3 failures with nptl
> (tst-cpuclocks),
> and probably the tests have some errors.
> I'll send you a full log next week.
> 
> I published months ago some test results (with very olf nptl revision).
> You can find it here :
> http://www.uclibc.org/~carmelo/uclibc-nptl_tests.html

Thanks.  I had 10 out of 16 TLS tests ok on mips.  After some
experimentation I got that up to 13 out of 16.  The TLS tests aren't
actively multithreaded, however.  They deal with different shared
objects (libraries?) loading and unloading, and the effects on the TLS
blocks and vector.  It's a guessing game whether changes to TLS will be
"correct" when moving on to the NPTL tests.  They should be, but the
documentation is really bad in some ways, not to mention the code itself
has almost no comments.  There's a lot of MIPS-only code, and that makes
it difficult to draw on other architectures' implementations for
guidance.  sjhill's README is also very much out of date.

Is it normal to see the resolve function in elfinterp.c run for the
shared libraries _before_ the main executable?  In other words, the
dependencies are processed first?  That's what I'm seeing.

I now see the reason for the second hash function.  The matched symbol's
st_value is the one that's needed (it's a TLS offset), but the original
hash function doesn't return a pointer to its Elf_sym.  Thus the need
for a second hash function.  I think this is MIPS-only as well.  And
maybe PowerPC, but I'm not going there.  I will try that next.

-- 
http://www.fastmail.fm - A no graphics, no pop-ups email service



More information about the uClibc mailing list