From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Jacobowitz To: Kimball Thurston , gdb@sources.redhat.com Subject: Re: gdb and dlopen Date: Tue, 16 Oct 2001 19:03:00 -0000 Message-id: <20011016220353.A9538@nevyn.them.org> References: <20011016161525.A1241@nevyn.them.org> <20011016213252.A8694@nevyn.them.org> X-SW-Source: 2001-10/msg00163.html On Tue, Oct 16, 2001 at 09:32:52PM -0400, Daniel Jacobowitz wrote: > On Tue, Oct 16, 2001 at 06:23:39PM -0700, Kimball Thurston wrote: > > It wasn't symbol reading inefficiency - or at least not directly. I > > thought that at first, but I grabbed the snapshot from Oct 5th - I > > haven't tried the latest yet, compiled it up with profiling info to > > find where gdb is spending it's time. The majority of the time is > > spent in child_xfer_memory - like 56% of the time (and most of that is > > spent calling ptrace to copy bytes around) - the child_xfer_memory > > seems to end up being called as a result of resetting breakpoints via > > a chain of other things. I don't know why (ignorance). I've attached a > > bzip of the profile data from the Oct 5th snapshot. Unfortunately, I > > don't know about the internals of gdb to know what memory it's > > transferring between processes. I tweaked on child_xfer_memory to not > > call ptid_get_pid quite so much, but that obviously had only a > > marginal improvement - it's all in ptrace and system calls - you can > > see the system calls hit pretty hard from a cpuload application. > > > > The plugins are very small (minus debug code info) - they should have > > only 3 exported functions, a few static functions, and their local > > data block has ~ 1K of data in it or so. Right now, there are about 50 > > of them. Can you give me more information, or a testcase? My suspicion that the link map was responsible seems to be wrong, since I can write a dummy application that loads 50 DSOs and debug it without any noticeable stalls at all. Is this application multithreaded, by chance, or at least linked to libpthread? The overhead in stopping and starting via the LinuxThreads debugging package, even without multiple threads, is so ridiculous that the times go through the roof. I think there's something which can be done about that. I see a staggering amount of time spent in svr4_current_sos, because target_read_string percolates down to thread_db_xfer_memory and thus to thread_db_thread_alive. We should be able to do some intelligent caching here. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer