This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: gdb and dlopen
On Wed, Oct 17, 2001 at 01:08:49AM -0400, Daniel Jacobowitz wrote:
> 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 ().
(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. I get an interesting result:
Without thread library:
loading 50 DSOs takes about 0.09 - 0.11 sec
With thread library but without that chunk:
1.47 - 1.56 sec
With thread library as it currently stands:
7.24 - 7.36 sec
We've definitely got some room for improvement here.
Amusingly, there are something like eight million calls to
ptid_get_pid. I'll send along a trivial patch to shrink the worst
offenders. I understand the opacity that functions over macros is
going for here, but a function that does 'return a.b;' and gets called
eight MILLION times is a little bit absurd, don't you think? Absurd
enough that it shows up as the second highest item on the profile.
--
Daniel Jacobowitz Carnegie Mellon University
MontaVista Software Debian GNU/Linux Developer