Re: gdb and dlopen

[Mark Kettenis <kettenis@science.uva.nl>]

Daniel Jacobowitz <drow@mvista.com> writes:

> > thread_db_thread_alive is EXPENSIVE!  And we do it on every attempt to
> > read the child's memory, of which we appear to have several hundred in
> > a call to current_sos ().
> 
> (and lwp_from_thread is a little expensive too...)
> 
> In the case I'm looking at, where I don't need to mess with either
> breakpoints or multiple threads (:P), I can safely comment out that
> whole check.

The FIXME on the check is a bit vague, and probably so since I didn't
exactly understand what was going on when I wrote that bit of code.  I
believe the need for the check arises from the fact that glibc 2.1.3
is buggy in the sense that TD_DEATH events are unusable.  This means
that we have no clean way to determine whether a thread exited or
not.  Therefore we have to check whether it is still alive.

If we declare glibc 2.1.3 broken, and force people to upgrade to glibc
2.2.x, we could assume that a thread stays alive between TD_CREATE and
TD_DEATH, and speed up thread_db_thread_alive considerably.

Something similar can be done for lwp_from_threads since assigning a
thread to a particular LWP can be reported too (never happens on Linux
since LinuxThreads uses a 1:1 mapping).

Note that if we assume that all threads see the same VM, and that the
initial LWP stays alive during the execution of the program, we could
simply use the process ID of the initial LWP for all memory transfers,
which would remove the need for those checks completely.

Mark