From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id cfbJE1hHzmCnbgAAWB0awg (envelope-from ) for ; Sat, 19 Jun 2021 15:36:56 -0400 Received: by simark.ca (Postfix, from userid 112) id 41A741F163; Sat, 19 Jun 2021 15:36:56 -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 EE2D51E813 for ; Sat, 19 Jun 2021 15:36:54 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id BC23B388A415 for ; Sat, 19 Jun 2021 19:36:53 +0000 (GMT) Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by sourceware.org (Postfix) with ESMTPS id 9CBAD3855031 for ; Sat, 19 Jun 2021 19:36:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 9CBAD3855031 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-out2.suse.de (Postfix) with ESMTPS id A64551FD34; Sat, 19 Jun 2021 19:36:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1624131400; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=hw9bL9/A8IBwGZYa6J3dIb5I4p6oduJew2JSdrsdG0c=; b=p/4t0PRXvAOnRrjRoj3HMOnVQXI+GF6oynGj4VMzY5b2O+hoqE3CSt/T0InEGPTpoPoQPM y4VlXocyCJdo3nLGT03m7zvclbSwJVpblTx55mLY4EoN/Fz4bIq7KbRQW1ES1C4fZWJ0GF 8oDzQ9+qdRm7I0P9sWCxB6Zmkbc3W2Q= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1624131400; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=hw9bL9/A8IBwGZYa6J3dIb5I4p6oduJew2JSdrsdG0c=; b=Uzipti2bdYoPxzeVsCUgWBJb8SUDsA2SDd+anUhs0qkClZdfWFSkRheTaA76qj68EL/XzM Xzdpue9MhR0IVyBg== Received: from imap3-int (imap-alt.suse-dmz.suse.de [192.168.254.47]) by imap.suse.de (Postfix) with ESMTP id 7F06D118DD; Sat, 19 Jun 2021 19:36:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1624131400; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=hw9bL9/A8IBwGZYa6J3dIb5I4p6oduJew2JSdrsdG0c=; b=p/4t0PRXvAOnRrjRoj3HMOnVQXI+GF6oynGj4VMzY5b2O+hoqE3CSt/T0InEGPTpoPoQPM y4VlXocyCJdo3nLGT03m7zvclbSwJVpblTx55mLY4EoN/Fz4bIq7KbRQW1ES1C4fZWJ0GF 8oDzQ9+qdRm7I0P9sWCxB6Zmkbc3W2Q= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1624131400; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=hw9bL9/A8IBwGZYa6J3dIb5I4p6oduJew2JSdrsdG0c=; b=Uzipti2bdYoPxzeVsCUgWBJb8SUDsA2SDd+anUhs0qkClZdfWFSkRheTaA76qj68EL/XzM Xzdpue9MhR0IVyBg== Received: from director2.suse.de ([192.168.254.72]) by imap3-int with ESMTPSA id TsBYHUhHzmAaDgAALh3uQQ (envelope-from ); Sat, 19 Jun 2021 19:36:40 +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> From: Tom de Vries Message-ID: Date: Sat, 19 Jun 2021 21:36:40 +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: <87bl83ykd9.fsf@tromey.com> Content-Type: multipart/mixed; boundary="------------9D884658CBB2CBE4150B77CA" Content-Language: en-US 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" This is a multi-part message in MIME format. --------------9D884658CBB2CBE4150B77CA Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit On 6/18/21 4:30 AM, Tom Tromey wrote: > Tom> I did an overnight build and test with the updated branch (5bc56d745fd) > Tom> and ran into some trouble. The first internal-error I investigated > Tom> happens when parsing the libstdc++ .debug package (so, it was not > Tom> specific to the test-case). It seems the branch has some trouble with > Tom> the dwz layout where an abbrev entry is shared between different CUs: > > Thank you for trying this, it uncovered several bugs. > As you can see I haven't gotten to the dwz testing yet... one of the > issues with DWARF, btw, is that there are just so many modes. > I.e., I haven't tried DWO or .debug_types yet either. > Yeah, very true. > I pushed some patches to fix the crashes but the result is so fast that > I suspect it is incorrect: > > (gdb) file libstdc++.so.6.0.28-10.2.1+git583-lp152.4.1.x86_64.debug > 2021-06-17 20:25:34.361 - command started > Reading symbols from libstdc++.so.6.0.28-10.2.1+git583-lp152.4.1.x86_64.debug... > 2021-06-17 20:25:34.406 - command finished > Command execution time: 0.075291 (cpu), 0.045521 (wall) > > (Though /bin/gdb is also pretty fast here, maybe I'm doing something > else wrong.) > > So, at least it doesn't crash, but more investigation is needed. > I'll probably add some code to make it easy to dump the index so it's > easier to see what the scanner recorded. Tried the updated branch and ran into a race condition, fixed in attached patch. Thanks, - Tom --------------9D884658CBB2CBE4150B77CA Content-Type: text/x-patch; charset=UTF-8; name="0001-Fix-race-condition-in-dwarf2_section_info-read.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline; filename*0="0001-Fix-race-condition-in-dwarf2_section_info-read.patch" Fix race condition in dwarf2_section_info::read It can occur in dwarf2_section_info::read that: - thread A sets readin to true, and buffer to nullptr, and then - thread B reads readin as true, returns and finds that buffer is nullptr= and concludes that there no such such section. Which is not true, it's= just that thread A hasn't finished reading it yet, which would make buffer !=3D nullptr. --- gdb/dwarf2/section.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/gdb/dwarf2/section.c b/gdb/dwarf2/section.c index 8e1c0197c85..e6940103d77 100644 --- a/gdb/dwarf2/section.c +++ b/gdb/dwarf2/section.c @@ -30,6 +30,8 @@ #include "objfiles.h" #include "complaints.h" =20 +#include + void dwarf2_section_info::overflow_complaint () const { @@ -118,10 +120,12 @@ dwarf2_section_info::empty () const void dwarf2_section_info::read (struct objfile *objfile) { + static std::mutex mutex; asection *sectp; bfd *abfd; gdb_byte *buf, *retbuf; =20 + std::lock_guard guard (mutex); if (readin) return; buffer =3D NULL; --------------9D884658CBB2CBE4150B77CA--