From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 595 invoked by alias); 3 Mar 2012 02:54:19 -0000 Mailing-List: contact archer-help@sourceware.org; run by ezmlm Sender: Precedence: bulk List-Post: List-Help: List-Subscribe: List-Id: Received: (qmail 582 invoked by uid 22791); 3 Mar 2012 02:54:18 -0000 X-SWARE-Spam-Status: No, hits=-6.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org From: Tom Tromey To: Daniel Jacobowitz Cc: Jan Kratochvil , archer@sourceware.org, Jakub Jelinek Subject: Re: Inter-CU DWARF size optimizations and gcc -flto References: <20120201132307.GA32578@host2.jankratochvil.net> <87hayio7ld.fsf@fleche.redhat.com> Date: Sat, 03 Mar 2012 02:54:00 -0000 In-Reply-To: (Daniel Jacobowitz's message of "Sun, 26 Feb 2012 10:08:38 -0500") Message-ID: <871upa9yyf.fsf@fleche.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.94 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2012-q1/txt/msg00017.txt.bz2 >>>>> "Daniel" == Daniel Jacobowitz writes: Daniel> You are correct, it does crush GDB :-) I routinely try - emphasis on Daniel> try - to use GDB on programs with between 2500 and 5500 shared Daniel> libraries. It's agonizing. I have another project I want to work on Daniel> first, and not much time for GDB lately, but this is absolutely on my Daniel> list to improve. I am curious how you plan to improve it. The plan I mentioned upthread is probably pretty good for scaling to distro-sized programs, say 200 shared libraries or less (this is LibreOffice or Mozilla). Maybe we could get a bit more by putting minsyms into the index. I am not so confident it would let gdb scale to 5000 shared libraries though. For that size I've had two ideas. First, and simplest, punt. Make the user disable automatic reading of shared library debuginfo (or even minsyms) and make the user explicitly mention which ones should be used -- either by 'sharedlibrary' or by a linespec extension. I guess this one would sort of work today. (I haven't tried.) Second, and harder, is the "big data" approach. This would be something like -- load all the debuginfo into a server, tagged by build-id, ideally with global type- and symbol-interning; then change gdb to send queries to the server and get back the minimal DWARF (or DWARF-esque bits) needed; crucially, this would be a global operation instead of per-objfile, so that gdb could exploit parallelism on the server side. Parallelism seems key to me. Parallelism on the machine running gdb probably wouldn't work out, though, on the theory that there'd be too much disk contention. Dunno, maybe worth trying. Tom