Some questions on uClinc-nptl port

[Carmelo AMOROSO]

Hi Steve, All
first of all sorry for this long mail, but I'm trying to collect all my 
major concerns regarding the uCLibc-nptl port.
Due to they are striclty correlated, I preferred to collect them into 
one post.
I'd like to clearify some aspects before proceeding with the "big-merge".
Feel free to reply/reject/discuss when you can.

---------------------------------------
_dl_calloc [dl-tls.c:56]:
It still has the bug of the size passed to _dl_malloc (I opened time 
onto uclibc bug tracking system).
Pass size and not __size.
- if ((result = _dl_malloc(__size)) != NULL)
+ {if ((result = _dl_malloc(size)) != NULL) {

---------------------------------------
_dl_determine_tlsoffset [dl-tls.c: 341 - 389]
The loop into the slotinfo should start from index 1 because it is 
indexed by the tls_modid;
so slotinfo[0] is never used to store information for TLS modules.
I know this code is taken from glibc, but it doesn't fit with uClibc 
ld.so implementation.
I experencied a lot of problem without this changes (assert failure and 
runtime problems).

- for (cnt = 0; slotinfo[cnt].map != NULL; ++cnt)
+ for (cnt = 1; slotinfo[cnt].map != NULL; ++cnt)

---------------------------------------
init_tls[dl-tls.c : 1004]
In the loop to fill the slotinfo's element, use accordingly an indexing 
policy 1 based.
You may initialize the counter to 1 (but you need to update the assert 
statement) or simply
use a pre-incremented index to access the array.

-            slotinfo[i].map = l;
-        ++i;
+            slotinfo[++i].map = l;

---------------------------------------
dlopen [libdl.c]
The _dl_init_static_tls(), if needed, is called only for the dynamically 
loaded DSO.
We may have other DSOs, loaded as dependencies of the dlopened one, that 
have a static tls model
(i.e. they may use the IE access model). So I expected to try to perform 
the static initialization for all of them
The test tls/tst-tls13 exploits this scenario.

---------------------------------------
do_dlclose [libdl.c : 801]
The code used to collect contiguous chunks of memory from the static TLS 
block (taken from glibc I know), in my opinion,
is broken when it is freeing a block that is (let me say) on the right 
side of the last one.
I think that the tls_free_end has to be extended on the right side by 
adding the tls_blocksize.
I posted a message to the glibc-alpha ML, but nobody took care of it. I 
don't have a test-case exploiting this
suspected bug. Does anybody agree with me ?

This is the code I'm referring to...

# elif TLS_DTV_AT_TP
                    if ((size_t) tls_lmap->l_tls_offset == tls_free_end)
                        /* Extend the contiguous chunk being reclaimed. */
-                        tls_free_end -= tls_lmap->l_tls_blocksize;
+                       tls_free_end += tls_lmap->l_tls_blocksize;

---------------------------------------
To finish, I've a question about dlclose. What happens to the TLS block 
lazily allocated by tls_get_address?
Which code is responsible to free its memory and clear the dtv entry?

Thanks for you patience

Carmelo