This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc 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: NPTL libthread_db changes for static debugging


On Fri, Mar 03, 2006 at 03:43:47AM -0800, Roland McGrath wrote:
> I don't really like that fake creation event.  It's not really right.
> 
> I have had this patch sitting in my tree for, well, I guess about a year
> and half.  I don't recall whether static pthreads was what this was about,
> but I can't off hand see what else it would have been.  This makes
> td_ta_map_lwp2thr, and thereby td_ta_thr_iter, fail with TD_NOTHR before
> the thread register is set up.  That should prevent the confused results
> you mentioned.  
> 
> This doesn't stop for the debugger as soon as things are initialized.  But
> I don't really see the need for that.  You can try map_lwp2thr again the
> next time the process stops for whatever reason.  You don't really need to
> know it until first real thread creation event.
> 
> What do you think?

It assumes the uninitialized value is zero.  Is that really going to
cut it?  It works for i686 and x86_64, but most other platforms don't
flush TLS state on exec - no point in wasting the kernel cycles
when they don't affect something as touchy as segment registers.

I had a previous draft of the GDB changes where I simply ignored errors
from td_ta_thr_iter and td_thr_get_info.  It works well enough on i686
and x86_64, but while I haven't tested it anywhere else, I'm pretty
sure it won't work on MIPS, SH, ARM, or IA-64.  After that I stopped
looking.

I just verified IA-64: immediately after exec r13 contains the previous
executable's TLS value.

So, it's nicer, but it doesn't work.

Another potential problem is that there's a window between the
initialization of TLS and the initialization of the first struct
pthread; at that point libthread_db will try to read things like the
LWP ID from the struct pthread even though they aren't initialized
until later in __pthread_initialize_minimal.  I can probably get
that to be a problem even in dynamic executables.  Not sure.

-- 
Daniel Jacobowitz
CodeSourcery


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