From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 77020 invoked by alias); 24 Feb 2016 15:30:37 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 76909 invoked by uid 89); 24 Feb 2016 15:30:33 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=auditing, skeptical, cus, daily X-HELO: gproxy7-pub.mail.unifiedlayer.com Received: from gproxy7-pub.mail.unifiedlayer.com (HELO gproxy7-pub.mail.unifiedlayer.com) (70.40.196.235) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with SMTP; Wed, 24 Feb 2016 15:30:26 +0000 Received: (qmail 1166 invoked by uid 0); 24 Feb 2016 15:30:20 -0000 Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy7.mail.unifiedlayer.com with SMTP; 24 Feb 2016 15:30:20 -0000 Received: from box522.bluehost.com ([74.220.219.122]) by CMOut01 with id NFWE1s00P2f2jeq01FWHEv; Wed, 24 Feb 2016 08:30:19 -0700 X-Authority-Analysis: v=2.1 cv=O8aq4nNW c=1 sm=1 tr=0 a=GsOEXm/OWkKvwdLVJsfwcA==:117 a=GsOEXm/OWkKvwdLVJsfwcA==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=PnD2wP_eR3oA:10 a=ezDAll7g0wUA:10 a=jFJIQSaiL_oA:10 a=NEAV23lmAAAA:8 a=6T-d8T7208rhM33SAH4A:9 Received: from [71.218.200.158] (port=60240 helo=pokyo) by box522.bluehost.com with esmtpsa (TLSv1.2:AES128-GCM-SHA256:128) (Exim 4.84) (envelope-from ) id 1aYbOJ-0003w2-7S; Wed, 24 Feb 2016 08:30:15 -0700 From: Tom Tromey To: Pedro Alves Cc: Simon Marchi , gdb@sourceware.org, Tom Tromey Subject: Re: Multi-threaded dwarf parsing References: <2c38d5c574de28faa9fc94fe4ed17d45@simark.ca> <56CD8EC0.3010304@redhat.com> Date: Wed, 24 Feb 2016 15:30:00 -0000 In-Reply-To: <56CD8EC0.3010304@redhat.com> (Pedro Alves's message of "Wed, 24 Feb 2016 11:06:40 +0000") Message-ID: <87lh6a6s8s.fsf@tromey.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.90 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Identified-User: {36111:box522.bluehost.com:elynrobi:tromey.com} {sentby:smtp auth 71.218.200.158 authed with tom+tromey.com} X-SW-Source: 2016-02/txt/msg00022.txt.bz2 >> According to his description (from https://github.com/tromey/gdb/wiki): >> "I think it doesn't help any real-world case". I'd like to ask you >> directly, Tom: now that you debug Firefox (i.e. a quite large program) >> daily with gdb, are you still of the same opinion? Of course, I'm also >> interested in what others have to say about that. Is it something that >> would have value, you think? It's been a while since I thought about that branch. I think it helps some scenarios, but maybe not as many as you'd like. In fact, I think it doesn't help the two of the three most typical ways I debug Firefox. (I realize this may not apply directly to your idea of reading each CU independently; this is just the state of that branch.) 1. Run Firefox, then attach. Here it is pretty normal for the attach to interrupt Firefox somewhere in libxul.so -- the largest library (so much larger that it is the only one that causes a noticeable pause at gdb startup). But, it seems to me that stopping somewhere in libxul.so should probably cause its debuginfo to be read. 2. Start gdb, set a breakpoint, then run Firefox. Here debuginfo for every library must be read in order to set the breakpoint correctly. The third scenario, which would be helped, is: 3. Start gdb, run Firefox, and try to reproduce a crash. In this situation gdb could read the debuginfo in the background and everything would work nicely. That said, I think my branch might have helped a tiny bit with scenario #1, because it prioritized the largest files when reading debuginfo. So, libxul.so would generally be read a bit earlier than it is now. Reading each CU independently seems like a good idea to me. I think it will stumble into various problems inside gdb, but I'd guess they are all surmountable with enough work. I think this could help with scenario #1. The ideal situation here would be to read just the CU (or CUs?) covering the stop address; then lazily read more as needed for types and such. I suppose it could also help #2 if enough parallelism is there to be had, though I'm a bit skeptical. >> So, in a word, are there any gotchas or good reasons not do take this >> path? Pedro> The obvious gotchas are of course all the globals, and coming up with Pedro> fine enough locking granularity that threads actually do run in parallel. I think the gotcha situation got worse since I wrote my patch. Now the DWARF reader can call into the type-printing system, which it didn't before. It wasn't clear to me that this was safe. ISTR there was some other change along these lines -- the DWARF reader calling out to some gdb module that it previously did not -- but I can't remember what it was any more. The DWARF reader also has many more modes (debug_types, dwz, dwo/dwp) than it did back then. So, this will require some careful auditing. FWIW my threading patches were written during my time at Red Hat and so you can use any part of that series without needing any paperwork from me. Tom