From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.ispras.ru (mail.ispras.ru [83.149.199.84]) by sourceware.org (Postfix) with ESMTPS id 142003857405 for ; Thu, 5 May 2022 10:53:03 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 142003857405 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=ispras.ru Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=ispras.ru Received: from [10.10.3.121] (unknown [10.10.3.121]) by mail.ispras.ru (Postfix) with ESMTPS id 949D340D4004; Thu, 5 May 2022 10:52:56 +0000 (UTC) Date: Thu, 5 May 2022 13:52:56 +0300 (MSK) From: Alexander Monakov To: Richard Biener cc: =?ISO-8859-15?Q?Martin_Li=A8ka?= , GCC Patches , Jan Hubicka Subject: Re: [PATCH] lto-plugin: add support for feature detection In-Reply-To: Message-ID: References: <63633ead-aa7e-c424-9851-ac332ac13df3@suse.cz> <27841a42-baef-d53e-c601-ad265030854d@suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-2.9 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2022 10:53:04 -0000 On Thu, 5 May 2022, Richard Biener via Gcc-patches wrote: > > I think they should simply try to not register LDPT_GET_SYMBOLS or > > LDPT_GET_SYMBOLS_V2 with the plugin in the onload hook and if > > that fails they will know the plugin doesn't support V3 only. I suppose > > it should work to call onload() multiple times (when only increasing the > > set of supported functions) until it returns LDPS_OK without intermediately > > dlclosing it (maybe call cleanup_handler inbertween). This should work > > for old plugin versions. > > > > That said, a better API extension compared to adding some random > > symbol like you propose is to enhance the return value from onload(), > > maybe returning an alternate transfer vector specifying symbol entries > > that will not be used (or return a transfer vector that will be used). > > We've been mostly versioning the symbol related hooks here. > > > > That said, I do not like at all this proposed add of a special symbol > > to flag exclusive v3 use. That's a hack and not extensible at all. > > Speaking of which, onload_v2 would be in order and should possibly > return some instantiation handle of the plugin that the linker could > instruct the plugin to dispose (reset ()?). I see the GCC implementation > of the plugin just has a single global state and it doesn't seem that it's > prepared for multiple onload() calls (but it might work by accident if > you never remove things from the support vector but only add). > > Without revamping the whole API onload_v2 could set the current > global state for the plugin based on the transfer vector and the reset() > API would discard the state (might also be redundant and implicitely > performed by the next onload_v2 call). > > onload_v2 could then also have an "output" transfer vector where the > plugin simply copies the entries it picked and dropped those it will > never call. We'd document the plugin may only pick _one_ of the versioned > API variants. > > That said, the heuristic outlined above might still work with the present > onload() API and existing implementations. Feels a bit weird to ask, but before entertaining such an API extension, can we step back and understand the v3 variant of get_symbols? It is not documented, and from what little I saw I did not get the "motivation" for its existence (what it is doing that couldn't be done with the v2 api). To me lack of documentation looks like a serious issue :/ Likewise, I don't really understand why mold cannot be flexible and efficiently service both the v2 and v3 variants without committing to one of those in advance. Alexander