NPTL libthread_db changes for static debugging
Daniel Jacobowitz
drow@false.org
Fri Mar 3 14:42:00 GMT 2006
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
More information about the Libc-alpha
mailing list