Question about elf/dl-load.c

[Florian Weimer <fw at deneb dot enyo dot de>]

I found this bit in _dl_map_object_from_fd:

	case PT_TLS:
	  if (ph->p_memsz == 0)
	    /* Nothing to do for an empty segment.  */
	    break;

	  l->l_tls_blocksize = ph->p_memsz;
	  l->l_tls_align = ph->p_align;
	  if (ph->p_align == 0)
	    l->l_tls_firstbyte_offset = 0;
	  else
	    l->l_tls_firstbyte_offset = ph->p_vaddr & (ph->p_align - 1);
	  l->l_tls_initimage_size = ph->p_filesz;
	  /* Since we don't know the load address yet only store the
	     offset.  We will adjust it later.  */
	  l->l_tls_initimage = (void *) ph->p_vaddr;

	  /* If not loading the initial set of shared libraries,
	     check whether we should permit loading a TLS segment.  */
	  if (__glibc_likely (l->l_type == lt_library)
	      /* If GL(dl_tls_dtv_slotinfo_list) == NULL, then rtld.c did
		 not set up TLS data structures, so don't use them now.  */
	      || __glibc_likely (GL(dl_tls_dtv_slotinfo_list) != NULL))
	    {
	      /* Assign the next available module ID.  */
	      l->l_tls_modid = _dl_next_tls_modid ();
	      break;
	    }

#ifdef SHARED
	  if (l->l_prev == NULL || (mode & __RTLD_AUDIT) != 0)
	    /* We are loading the executable itself when the dynamic linker
	       was executed directly.  The setup will happen later.  */
	    break;

# ifdef _LIBC_REENTRANT
	  /* In a static binary there is no way to tell if we dynamically
	     loaded libpthread.  */
	  if (GL(dl_error_catch_tsd) == &_dl_initial_error_catch_tsd)
# endif
#endif
	    {
	      /* We have not yet loaded libpthread.
		 We can do the TLS setup right now!  */

	      void *tcb;

	      /* The first call allocates TLS bookkeeping data structures.
		 Then we allocate the TCB for the initial thread.  */
	      if (__glibc_unlikely (_dl_tls_setup ())
		  || __glibc_unlikely ((tcb = _dl_allocate_tls (NULL)) == NULL))
		{

And so on.  My question is this: Can we actually enter the final part,
under “We can do the TLS right now!” in a shared build?

I doubt that because during the initial link, we will hit the second
break statement for libraries, and the third break statement for the
main program.  Before user code runs, rtld.c sets up the TLS data
structures, so any future dlopen calls hit the second break again
because GL(dl_tls_dtv_slotinfo_list) != NULL at this point.

Is this reasoning correct?  I put in a debug printf and ran the elf
tests, and there was nothing printed.