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] |
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] |