Re: gdb and dlopen

[Daniel Jacobowitz <drow at mvista dot com>]

On Tue, Oct 16, 2001 at 11:17:19PM -0400, Andrew Cagney wrote:
> Thread support was given a serious overhall in 5.0 (it became 
> maintainable and fixable).
> 
> Can you try this with/without the thread library linked in?  Everytime 
> GDB sees a shared library being loaded it goes frobbing around to see if 
> it contains some thread support code.  That could be the problem.

I can verify that this's the problem.  It takes negligible time (still
more ptraces than it should, maybe, but not by too much) for a
non-threaded testcase.  Link in -lpthread, and the time skyrockets.

thread_db is, plain and simply, horribly slow.  We could speed it up
tremendously if we cached memory reads from the child across periods
where we knew it was safe to do so; I'll have to think about how to do
this.  Meanwhile, the real speed penalty seems to be:

      /* FIXME: This seems to be necessary to make sure breakpoints
         are removed.  */
      if (!target_thread_alive (inferior_ptid))
        inferior_ptid = pid_to_ptid (GET_PID (inferior_ptid));
      else
        inferior_ptid = lwp_from_thread (inferior_ptid);

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

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