From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id X1nTHHSq0WDXVAAAWB0awg (envelope-from ) for ; Tue, 22 Jun 2021 05:16:36 -0400 Received: by simark.ca (Postfix, from userid 112) id 664A31F1F2; Tue, 22 Jun 2021 05:16:36 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-0.5 required=5.0 tests=DKIM_SIGNED, MAILING_LIST_MULTI,RDNS_DYNAMIC,T_DKIM_INVALID,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (ip-8-43-85-97.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 28FC11E01F for ; Tue, 22 Jun 2021 05:16:35 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 7C6F6394D828 for ; Tue, 22 Jun 2021 09:16:34 +0000 (GMT) Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by sourceware.org (Postfix) with ESMTPS id 5DD953833005 for ; Tue, 22 Jun 2021 09:16:23 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 5DD953833005 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=suse.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=suse.de Received: from imap.suse.de (imap-alt.suse-dmz.suse.de [192.168.254.47]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id 55D7621960; Tue, 22 Jun 2021 09:16:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1624353382; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=WrjdgynLKurOKMIbbmIDGmcuRT7MCZoylmU4d89/2ok=; b=xyESyzW9qlHUpdiXRg6Glz9giY+4KXLtzRoFVNe7huUH040ApKbeItUA2blaz4iLAfC7BZ 8V2S/K7rVXjiUtfwrVJq7yDrV/ZsjglBX0SVzHenMy7AQe6yDs0BTSFKjfltflflE/lcy+ Y4R8py7iP7eFvv6HOzMnfbdUstDekCA= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1624353382; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=WrjdgynLKurOKMIbbmIDGmcuRT7MCZoylmU4d89/2ok=; b=zyTep3ollLqTO6f4pgaFqBtr5R9xZiuvnmHTTKyGTz8dpxCD+plWEInUpTh48eoBkKF0EG RCGCswxArtU2ARBQ== Received: from imap3-int (imap-alt.suse-dmz.suse.de [192.168.254.47]) by imap.suse.de (Postfix) with ESMTP id 335A3118DD; Tue, 22 Jun 2021 09:16:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1624353382; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=WrjdgynLKurOKMIbbmIDGmcuRT7MCZoylmU4d89/2ok=; b=xyESyzW9qlHUpdiXRg6Glz9giY+4KXLtzRoFVNe7huUH040ApKbeItUA2blaz4iLAfC7BZ 8V2S/K7rVXjiUtfwrVJq7yDrV/ZsjglBX0SVzHenMy7AQe6yDs0BTSFKjfltflflE/lcy+ Y4R8py7iP7eFvv6HOzMnfbdUstDekCA= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1624353382; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=WrjdgynLKurOKMIbbmIDGmcuRT7MCZoylmU4d89/2ok=; b=zyTep3ollLqTO6f4pgaFqBtr5R9xZiuvnmHTTKyGTz8dpxCD+plWEInUpTh48eoBkKF0EG RCGCswxArtU2ARBQ== Received: from director2.suse.de ([192.168.254.72]) by imap3-int with ESMTPSA id 6K+MC2aq0WBwJQAALh3uQQ (envelope-from ); Tue, 22 Jun 2021 09:16:22 +0000 Subject: Re: [RFC][gdb/symtab] Lazy expansion of full symbol table To: Tom Tromey References: <20210614093908.GA22709@delia> <87pmwoxj3j.fsf@tromey.com> <533bf7e4-d96c-a6b7-8c37-a4141ebdc761@suse.de> <87im2fxnr7.fsf@tromey.com> <87bl83ykd9.fsf@tromey.com> <8735tcxuxq.fsf@tromey.com> From: Tom de Vries Message-ID: <0cd9236e-3696-1b5e-766b-2b860018129c@suse.de> Date: Tue, 22 Jun 2021 11:16:21 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: <8735tcxuxq.fsf@tromey.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: gdb-patches@sourceware.org Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" On 6/20/21 8:17 PM, Tom Tromey wrote: >>>>>> "Tom" == Tom de Vries writes: > > Tom> I found out that the precondition for using std::lower_bound of the > Tom> vector being sorted in a certain way is not valid: > [...] > > While debugging a different failure today, I found that the 'find' > method wasn't waiting for the future to resolve, so it was allowing use > of the vector before it was ready. This is fixed on the branch now. > > I have 125 regressions to go. I did a build and reg-test with the current state of branch, and the two patches I've mentioned. I get: ... $ grep -c ^FAIL: gdb.sum 218 $ grep -c ^ERROR: gdb.sum 193 ... Possibly more fails because of using --with-separate-debug-dir=/usr/lib/debug ? Just to give you another data point, not sure if this is terribly relevant. I also did a speed test with my running example of branch tip vs merge base, and got: ... $ DEBUGINFOD_URLS= DBG=~/dwz/measure/time.sh ./gdb.sh -q -batch lto/cc1 maxmem: 348472 real: 0.50 user: 1.09 system: 0.09 $ DEBUGINFOD_URLS= DBG=~/dwz/measure/time.sh ./gdb.sh -q -batch lto/cc1 maxmem: 509212 real: 2.58 user: 2.53 system: 0.09 ... which is a nice factor 5 speedup, or 2 seconds in absolute terms. However, when I do also set the breakpoint: ... $ DEBUGINFOD_URLS= DBG=~/dwz/measure/time.sh ./gdb.sh -q -batch lto/cc1 -ex "b do_rpo_vn" Breakpoint 1 at 0xd40e30: do_rpo_vn. (2 locations) maxmem: 1011140 real: 5.09 user: 5.54 system: 0.24 $ DEBUGINFOD_URLS= DBG=~/dwz/measure/time.sh ./gdb.sh -q -batch lto/cc1 -ex "b do_rpo_vn" Breakpoint 1 at 0xd40e30: do_rpo_vn. (2 locations) maxmem: 873952 real: 5.55 user: 5.37 system: 0.24 ... I'm left with just 0.5 seconds speedup. I investigated whether that was caused by more CUs being expanded, but that doesn't seem to be the case. So I'm tentatively drawing the conclusion that it makes sense for me to continue on the lazy expansion effort. Thanks, - Tom > At the same time I think part of the > quick function code still has to be rewritten; I haven't tested DWO yet; > and I am not sure all the modes that Ada supports are handled by the > lookup code. So there's still a reasonable amount to do. Then of > course there's the final rebasing to shape it up, the branch history is > particularly ugly at this moment. > > Tom >