From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from nikam.ms.mff.cuni.cz (nikam.ms.mff.cuni.cz [195.113.20.16]) by sourceware.org (Postfix) with ESMTPS id A827E3858C56 for ; Mon, 16 May 2022 09:50:18 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org A827E3858C56 Received: by nikam.ms.mff.cuni.cz (Postfix, from userid 16202) id 3E2A2282F1C; Mon, 16 May 2022 11:50:17 +0200 (CEST) Date: Mon, 16 May 2022 11:50:17 +0200 From: Jan Hubicka To: Martin =?iso-8859-2?Q?Li=B9ka?= Cc: Richard Biener , Alexander Monakov , GCC Patches Subject: Re: [PATCH] lto-plugin: add support for feature detection Message-ID: References: <97c39ec3-33f-36e1-ebd7-498e3772c9a3@ispras.ru> <245cc396-ad40-cb98-b171-e56e3d9c1c2@ispras.ru> <69142cd0-1947-e7d3-50ad-d9010f46fbf0@suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <69142cd0-1947-e7d3-50ad-d9010f46fbf0@suse.cz> X-Spam-Status: No, score=-5.2 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, KAM_SHORT, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) 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: Mon, 16 May 2022 09:50:20 -0000 > On 5/16/22 11:25, Jan Hubicka via Gcc-patches wrote: > >> > >> Sure having a 'plugin was compiled from sources of the GCC N.M compiler' > >> is useful if bugs are discovered in old versions that you by definition cannot > >> fix but can apply workarounds to. Note the actual compiler used might still > >> differ. Note that still isn't clean API documentation / extension of the plugin > >> API itself. As of thread safety we can either add a claim_file_v2_hook > >> or try to do broader-level versioning of the API with a new api_version > >> hook which could also specify that with say version 2 the plugin will > >> not use get_symbols_v2 but only newer, etc. The linker would announce > >> the API version it likes to use and the plugin would return the > >> (closest) version > >> it can handle. A v2 could then also specify that claim_file needs to be > > > > Yep, I think having the API version handshake is quite reasonable way to > > go as the _v2,_v3 symbols seems already getting bit out of hand and we > > essentially have 3 revisions of API to think of > > (first adding LDPR_PREVAILING_DEF_IRONLY_EXP, second adding > > GET_SYMBOLS_V3 and now we plan third adding thread safety and solving > > the file handler problems) > > How should be design such a version handshake? As richi outlined. We need to assign version number of the API (with 1, 2, 3 defind to match existing revisions) and define version 4 which will have have way for plugin to announce maximal api version supported and linker telling plugin what API version it wants to work with. That shold be min(linker_api, plugin_api) Since revisions happens relatively rarely, I think we should be able to stay with single number determining it. > > > > >> thread safe, or that cleanup should allow a followup onload again with > >> a state identical to after dlopen, etc. > >> > >> Is there an API document besides the header itself somewhere? > > > > There is https://gcc.gnu.org/wiki/whopr/driver > > I wonder if this can't be moved into more official looking place since > > it looks like it is internal to GCC WHOPR implementation this way. > > We can likely add it here: > https://gcc.gnu.org/onlinedocs/gccint/LTO.html#LTO > > What do you think? I can port it. I am bit worried that it is place LLVM developers will not look at since name "GCC internals" suggests it is internal to GCC. It is not. However perhaps we can link it from binutils docs, plugin header and gcc plugin source to make it hopefully obvious enough. Maybe binutils docs would be an alternative. Yet we want other linkers support it: I am really happy mold now supports plugin API, but if lld and MacOS linker had it it would make our life easier. Honza > > Martin > > > > > Honza > >> > >> Richard. >