This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Amusing problem in current libthread_db


The reason that code is needed for linuxthreads is that the thread
descriptor might be uninitialized.  The main thread and the manager thread
are always reported by td_ta_thr_iter.  However, early on their descriptors
are all zeros and so td_thr_get_info et al need to be able to cope with
that.  It might make more sense not to report any threads at all before
they are initialized enough to report useful information.  But I think that
was deemed a more risky change (vs possible presumptions of old gdbs, etc)
than faking the all-zeros responses in the early stages.  

The reason this wasn't an issue before and got changed was that the array
of thread descriptors used to be in initialized data, where the first two
elements were initialized nonzero to set up the the main and manager threads.
Now the whole array is in uninitialized so it can go in bss and not take up
space on disk; thus the main and manager threads' elements start out zero too.

td_thr_get_info does a somewhat more convincing job of faking info when
dealing with an uninitialized descriptor in the inferior, i.e. always just
use the main thread in that case.  td_thr_getgregs et al could be made to
do that.


Thanks,
Roland


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