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 25D603857364 for ; Mon, 16 May 2022 09:26:01 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 25D603857364 Received: by nikam.ms.mff.cuni.cz (Postfix, from userid 16202) id A7904282EF1; Mon, 16 May 2022 11:25:59 +0200 (CEST) Date: Mon, 16 May 2022 11:25:59 +0200 From: Jan Hubicka To: Richard Biener Cc: Rui Ueyama , Alexander Monakov , GCC Patches Subject: Re: [PATCH] lto-plugin: add support for feature detection Message-ID: References: <7788e58e-ce41-d25b-eefe-5f9c966a2ff2@ispras.ru> <97c39ec3-33f-36e1-ebd7-498e3772c9a3@ispras.ru> <245cc396-ad40-cb98-b171-e56e3d9c1c2@ispras.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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:26:04 -0000 > > 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) > 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. Honza > > Richard.