This is the mail archive of the libc-hacker@sourceware.cygnus.com mailing list for the glibc project.

Note that libc-hacker is a closed list. You may look at the archives of this list, but subscription and posting are not open.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: twp bigger changes


   From: Ulrich Drepper <drepper@redhat.com>
   Date: 05 May 2000 01:14:32 -0700

   - I've changed the internal thread descriptor of the thread library a bit.
     This will have no visible changes for the user.  The only possible
     problem could be gdb if the old thread debugging mechanism is used.  But
     since gdb now uses libthread_db this shouldn't be a problem.  libthread_db
     is there for just these cases.

GDB 5.0 will indeed use libthread_db if it is available.  However, I
suspect people will be somewhat dissappointed when they learn that it
has some annoying limitations, like terminating the program when one
of its threads terminate, and not being able to handle more than 30
thread creations.  I've sent fixes for this problem to Michael Snyder,
but since they're rather big, they'll probably not make the 5.0
release.  Moreover, to make it work in a reliable way, I need the
thread death events notifications and those don't work with the glibc
2.1.3 libthread_db.  So perhaps it would be a good idea to release a
glibc 2.1.4 with my libthread_db fixes.  That would make it possible
for the GDB folks to tell people to upgrade to 2.1.4 if they want to
debug threads under Linux.

     The change is necessary since there are changes coming down the road which
     will depend on the free room at the beginning of the structure.  These
     changes are mainly dealing with thread-local data which is handled by the
     compiler.  We are currently defining an appropriate ABI in the IA-64
     working groups and I'm making sure the same mechanisms can be used for
     other architectures which have a thread-local register (or a relative
     wasy way to get it, like the Alpha).  Since it is impractical to customize
     the compiler to look at the end of the internal structure it is better
     to have a fixed offset.

I don't think it would be very smart to make the compiler dependent on
the internals of the threads implementation.  I assume that the
proposal is some abstract ABI definition like:

   "On the x86 %gs shall point to a thread-local data structure with
    the following layout: ..."

But if not, I would like to express my serious concerns.

Also note that, if you actually any of the segment registers to point
at such a data structure, the number of entries in a LDT is limited,
and that some OS'es have a per-process (i.e. per-VM space) LDT instead
of a per-thread LDT.

I sincerely hope that there would be a public discussion before things
would be decided for existing widely deployed architectures, and that
it will not happen behind closed doors as much of this IA-64 stuff
seems to be done.

Mark

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]