On Tue, 21 Apr 2009 07:42 +0200, "Carmelo AMOROSO" <[email protected]> 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 _______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
