From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.polymtl.ca (smtp.polymtl.ca [132.207.4.11]) by sourceware.org (Postfix) with ESMTPS id 82AB43858002 for ; Tue, 30 Mar 2021 15:14:20 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 82AB43858002 Received: from simark.ca (simark.ca [158.69.221.121]) (authenticated bits=0) by smtp.polymtl.ca (8.14.7/8.14.7) with ESMTP id 12UFEDCn031584 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 30 Mar 2021 11:14:18 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp.polymtl.ca 12UFEDCn031584 Received: from [10.0.0.11] (192-222-157-6.qc.cable.ebox.net [192.222.157.6]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 9F44A1E789; Tue, 30 Mar 2021 11:14:13 -0400 (EDT) Subject: Re: GDB 10.2 Release: Proposing Mar 13-14 for official GDB 10.2 release To: Tom Tromey , Joel Brobecker Cc: Simon Marchi , gdb-patches@sourceware.org References: <20210306064611.GB807147@adacore.com> <06d96113-d09b-993f-0f55-00c297b4e591@simark.ca> <20210310024850.GA247585@adacore.com> <17184b08-d7e7-a62c-b689-35ab3f179f06@polymtl.ca> <20210316034551.GE3188@adacore.com> <875z19dyju.fsf@tromey.com> From: Simon Marchi Message-ID: <9697bf68-3e20-364e-6fed-3195d38dc00a@polymtl.ca> Date: Tue, 30 Mar 2021 11:14:13 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: <875z19dyju.fsf@tromey.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Poly-FromMTA: (simark.ca [158.69.221.121]) at Tue, 30 Mar 2021 15:14:13 +0000 X-Spam-Status: No, score=-10.2 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, NICE_REPLY_A, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org 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: , X-List-Received-Date: Tue, 30 Mar 2021 15:14:22 -0000 On 2021-03-30 1:02 a.m., Tom Tromey wrote: >>> diff --git a/gdb/dwarf2/read.c b/gdb/dwarf2/read.c >>> index 704ba9f36655..5d9256bece1e 100644 >>> --- a/gdb/dwarf2/read.c >>> +++ b/gdb/dwarf2/read.c >>> @@ -1954,7 +1954,8 @@ dwarf2_has_info (struct objfile *objfile, >>> doesn't require relocations and if there aren't partial symbols >>> from some other reader. */ >>> if (!objfile_has_partial_symbols (objfile) >>> - && !gdb_bfd_requires_relocations (objfile->obfd)) >>> + && !gdb_bfd_requires_relocations (objfile->obfd) >>> + && 0) >>> { >>> /* See if one has been created for this BFD yet. */ >>> per_bfd = dwarf2_per_bfd_bfd_data_key.get (objfile->obfd); >>> >>> We can then take our time to look at a proper fix for master. > > Joel> It's quite nice to see that this feature could be disabled with > Joel> a one-liner like this. > > Joel> Unless Tom has other ideas, this seems like the way to go for me. > > Sorry I didn't respond to this earlier. > I think it's fine for the branch. > > I came up with a complicated plan for the trunk, but after some > reflection, I think a better plan is to notice OBJF_READNOW and refuse > to do any sharing in this case. That is, it's your patch, but replacing > "0" with a check of OBJF_READNOW. The appended probably has the wrong > line numbers but it shows the idea. > > This -readnow stuff is an optimization, which in retrospect is kind of > silly, because on the whole I'd rather people not use -readnow anyway, > so why bother optimizing. But when I added the gdb-index code, I > noticed the possibility and I guess I couldn't resist. > > Tom > > diff --git a/gdb/dwarf2/read.c b/gdb/dwarf2/read.c > index 11cdcd02d0a..ec044ab66e5 100644 > --- a/gdb/dwarf2/read.c > +++ b/gdb/dwarf2/read.c > @@ -1883,9 +1883,11 @@ dwarf2_has_info (struct objfile *objfile, > { > dwarf2_per_bfd *per_bfd; > > - /* We can share a "dwarf2_per_bfd" with other objfiles if the BFD > - doesn't require relocations. */ > - if (!gdb_bfd_requires_relocations (objfile->obfd))G > + /* We can share a "dwarf2_per_bfd" with other objfiles if the > + BFD doesn't require relocations, and if -readnow was never > + requested. */ > + if (!gdb_bfd_requires_relocations (objfile->obfd) > + && (objfile->flags & OBJF_READNOW) == 0) > { > /* See if one has been created for this BFD yet. */ > per_bfd = dwarf2_per_bfd_bfd_data_key.get (objfile->obfd); This is fine with me, and I think it's sufficient for now. It passes the test I wrote, so I'll adjust my patch to use this and post a v2. In the general case, I'm not convinced that there aren't more problems like this, where you load the same BFD with two different "quick" methods (as mentioned in my commit message). We currently handle the psymtabs -> index case (commit efb763a5ea35), necessary for when the index-cache is on. In that case, we just keep using the already-created psymtabs the second time around, the index is just not used. But imagine an index -> psymtabs case. I imagine we could eventually have a "-no-index" switch to the file command and/or a "set use-index on/off" parameter, to tell GDB to not use any index. That could be useful in case the index gives you some trouble and you would like to read the file without it. So you could do "file bin" first and "file -no-index bin" second. The dwarf2_per_bfd is created using the index the first time, but we wouldn't want to re-use that dwarf2_per_bfd the second time. Only sharing the dwarf2_per_bfd between objfiles that use the same "quick" method would make me more confident that we won't hit other such problematic cases. Simon