[NPTL] Questions about testing

Dan E trg_info at mailhaven.com
Wed Apr 22 03:25:33 UTC 2009


On Tue, 21 Apr 2009 07:42 +0200, "Carmelo AMOROSO"
<carmelo.amoroso at st.com> wrote:
> Dan E wrote:
> > Thanks.  I had 10 out of 16 TLS tests ok on mips.  After some
> > experimentation I got that up to 13 out of 16.  
> what changes ? common code is stable and correct, I think.
> The TLS tests aren't

The TLS tests are written badly, but they're better than nothing.  I'm
relying very much on the fact that the common code works.  I didn't
change any of it, I only added a lot of _dl_dprintf() statements to see
what it was doing.  Most of my hacking was in elfinterp.c for mips. 
Until I decided to write a hash2 function.

> > 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.
> 
> the hash2 function should be removed, but the calling code must be
> adapted accordingly. The new hash function I implemented with the
> extra tpnt pointer for the tls should be enough; sh and arm are
> using it correclty. MIPS development was stoppped since a lot of
> time. So if you have time to update the MIPS part for using the hash
> new function, it's welcome.

The value passed back by the hash function - ignored by the mips code
until now - is very important.  My hash2 function was written to pass
that value back to the caller indirectly.  I see now how to use the
result in order to arrive at the correct relocation value.  So my hash2
function isn't needed after all.  That's good.  No need to fool around
inside dl-hash.c.

> Don't hesitate to ask on TLS part, I spent a lot of time on this in
> the past ;-)

I can tell :)  I now have 15 of 16 TLS tests passed.  tst-tls15 is the
only one that fails.  It gives "unexpectedly succeeded to open
tst-tlsmod15a.so".  It looks like dlopen() should fail for that .so
since 'extern int nonexistent_dummy_var' isn't defined anywhere.  But
dlopen() succeeds instead.  In elfinterp.c's
_dl_perform_mips_global_got_relocations() function the symbol gets
resolved to 0, which is correct I think.  Shouldn't _dl_fixup() fail
after that when RTLD_NOW is set and the symbol doesn't exist anywhere?

A question about NPTL thread ids...

In the test/nptl programs, the first call to pthread_create() always
returns a thread handle that has tid=0.  If I create more than 1 thread,
the tids go 0,1,2,3 etc.  Inside libpthread/nptl/pthreadP.h the macro
INVALID_TD_P(pd) says a tid < zero is invalid.  This is causing a lot of
problems in the test programs.  All the tst-cancel tests fail because
pthread_cancel() immediately rejects anything with tid=0.  Any thoughts?

-- 
http://www.fastmail.fm - Accessible with your email software
                          or over the web



More information about the uClibc mailing list