Re: gdb and dlopen

[Daniel Jacobowitz <drow@mvista.com>]

On Wed, Oct 17, 2001 at 04:59:32PM +0200, Mark Kettenis wrote:
> 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.

(Shouldn't there be a way for us to tell when a thread dies without
receiving the TD_DEATH event anyway?  We -are- attached to all threads,
and LinuxThreads threads are all separate processes...)

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

I'm not entirely comfortable with that assumption, especially since
this is in thread-db rather than the LinuxThreads specific code.  But
perhaps we could introduce a target method saying what PID to use for
reads?  Then we could make Linux (I'm perfectly comfortable with not
supporting thread debugging on 2.1.3...) simply return the PID without
any expensive checks.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer