Re: Assignment of GDT entries

[Jeremy Fitzhardinge <jeremy@goop.org>]

Albert Cahalan wrote:
> So if I grabbed the first two slots before glibc got to
> mess with them, glibc wouldn't break horribly?

glibc would be happy with anything it got; if you grabbed all 3 TLS 
slots it would probably be upset.

> If I grabbed one slot and glibc grabbed another, Wine
> would be OK with the third instead of the second?

Presumably.

> So basically it's not allowed to just grab the 3rd slot?
Eh?  You mean there's no "allocate and return TLS slot #N" operation?  
No, but all the TLS slots should be interchangeable.  Once you've got 
your entry numbers and worked out your selector values, you can just use 
them.

> What if I want to find out what is already in use?
> Am I supposed to iterate over all 8191 possible
> GDT entries? How do I even tell how many slots
> are available without using them all up?
The kernel reserves 3 slots in the GDT for usermode use, which are 
per-thread.  If you want more segment descriptors, you can always 
allocate an LDT.

> Eeeeeeew. Well this was documented exactly nowhere.
> The man page is even vague about entry_number,

man set_thread_area has this as paragraph 2:

      When  set_thread_area() is passed an entry_number of -1, it uses a free
      TLS entry. If set_thread_area() finds a free TLS entry,  the  value  of
      u_info->entry_number  is  set  upon  return  to  show  which  entry was
      changed.

which seems pretty clear to me.  A quick run with strace on any binary 
shows this in action:

   set_thread_area({entry_number:-1 -> 6, base_addr:0xb7fb06c0,
   limit:1048575, seg_32bit:1, contents:0, read_exec_only:0,
   limit_in_pages:1, seg_not_present:0, useable:1}) = 0

   J
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/