From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from rock.gnat.com (rock.gnat.com [205.232.38.15]) by sourceware.org (Postfix) with ESMTP id 4ECA93851416 for ; Tue, 30 Mar 2021 07:59:49 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 4ECA93851416 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=adacore.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=brobecker@adacore.com Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 26383116434; Tue, 30 Mar 2021 03:59:49 -0400 (EDT) X-Virus-Scanned: Debian amavisd-new at gnat.com Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id yKeX5H3EaCAk; Tue, 30 Mar 2021 03:59:49 -0400 (EDT) Received: from float.home (localhost.localdomain [127.0.0.1]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by rock.gnat.com (Postfix) with ESMTPS id BAE0B1163FA; Tue, 30 Mar 2021 03:59:48 -0400 (EDT) Received: by float.home (Postfix, from userid 1000) id 22707A1242; Tue, 30 Mar 2021 11:59:44 +0400 (+04) Date: Tue, 30 Mar 2021 11:59:44 +0400 From: Joel Brobecker To: Tom Tromey Cc: Simon Marchi , Simon Marchi , gdb-patches@sourceware.org Subject: Re: GDB 10.2 Release: Proposing Mar 13-14 for official GDB 10.2 release Message-ID: <20210330075944.GE11111@adacore.com> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <875z19dyju.fsf@tromey.com> X-Spam-Status: No, score=-10.1 required=5.0 tests=BAYES_00, GIT_PATCH_0, KAM_DMARC_STATUS, SPF_HELO_NONE, 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 07:59:50 -0000 Hi Tom, On Mon, Mar 29, 2021 at 11:02:13PM -0600, 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. Great, thank you! Speaking of the branch, given your patch below, perhaps we can have best of both worlds if we go with the solution you suggest? If we could converge on that by the time the weekend comes, I think it would be reasonable to backport your patch to the branch as well. > 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, Same here. > so why bother optimizing. But when I added the gdb-index code, I > noticed the possibility and I guess I couldn't resist. Lol. > 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)) > + /* 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); Sounds like a good idea, especially if that avoids a complicated plan to make it work. The only small comment I have is that it would be useful, I think, to explain why we say we cannot share the dwarf2_per_bfd when -readnow is in effect (too complicated to support and not worth the effort considering that performance is typically not as important in the case of -readnow). -- Joel