From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17229 invoked by alias); 15 Mar 2012 12:51:26 -0000 Mailing-List: contact archer-help@sourceware.org; run by ezmlm Sender: Precedence: bulk List-Post: List-Help: List-Subscribe: List-Id: Received: (qmail 17218 invoked by uid 22791); 15 Mar 2012 12:51:24 -0000 X-SWARE-Spam-Status: No, hits=-1.3 required=5.0 tests=AWL,BAYES_00,SPF_FAIL X-Spam-Check-By: sourceware.org Date: Thu, 15 Mar 2012 12:51:00 -0000 From: Gary Benson To: Daniel Jacobowitz Cc: Tom Tromey , Jan Kratochvil , archer@sourceware.org, Jakub Jelinek Subject: Re: Inter-CU DWARF size optimizations and gcc -flto Message-ID: <20120315125107.GB3076@redhat.com> Mail-Followup-To: Daniel Jacobowitz , Tom Tromey , Jan Kratochvil , archer@sourceware.org, Jakub Jelinek References: <20120201132307.GA32578@host2.jankratochvil.net> <87hayio7ld.fsf@fleche.redhat.com> <871upa9yyf.fsf@fleche.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-SW-Source: 2012-q1/txt/msg00036.txt.bz2 Daniel Jacobowitz wrote: > There's also a lot of room for profiling to identify bad algorithms; > I think we spend a lot of time reading the solib list from the > inferior (something I thought I and others had fixed thoroughly > already...) and I routinely hit inefficient algorithms e.g. during > "next". I did some work on this recently. On my setup (with gdb and the inferior on the same machine) it was spending a huge chunk of time regenerating symbol tables every time the solib_event_breakpoint hit. The final patch I committed is here: http://www.cygwin.com/ml/gdb-patches/2011-10/msg00068.html If you're seeing some sort of qsort comparison function at the top of the profile it could be that something is bypassing this. If you find the time is taken up mostly with transferring data from the inferior to gdb (I never tried remote, for instance) then you might be interested in some work I did last year on a SystemTap based interface between glibc and gdb that should be able to be extended to allow selective reading of the solib list. That's waiting on Sergio's SystemTap stuff... also the glibc maintainers seem hostile to the idea of us inserting SystemTap probes in there. I can dig up the code I had for this if you're interested. I also had a patch floating around that disabled the solib event breakpoint under certain conditions, but I think the ambiguous linespec stuff makes this patch invalid as you always have to be looking out for new functions turning up. If you're interested the thread is http://www.cygwin.com/ml/gdb-patches/2011-09/msg00156.html but it's probably useless :( Cheers, Gary -- http://gbenson.net/