From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt1-x836.google.com (mail-qt1-x836.google.com [IPv6:2607:f8b0:4864:20::836]) by sourceware.org (Postfix) with ESMTPS id 7C4803858C50 for ; Mon, 16 May 2022 10:22:37 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 7C4803858C50 Received: by mail-qt1-x836.google.com with SMTP id t16so11661306qtr.9 for ; Mon, 16 May 2022 03:22:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Fc8aEcqGbkZWkDtgQHDzUcoz7nUxN8/kPEEyuHG4m/8=; b=Qa+vivHi1VaVEgPxDHcutd+aVXn409Vz7Pu1ScarXDjVpZ4eENZLJB3YdeaASVLlSM Er/QXHobGhQQgezfuBNwkDl5pfv83aIMYZ2E9+Xaa0/N6ua9Yj4qlETA6ft2Kyi3UXWn Eyxw/n0b18Z2Z4IOPUnSaj8JkgzB16rINB9mWpQpTCkFgY/8J4f9rEk3I8lfcloPFbRp qd7qZAHgopTlD79cocAI8j9Xh52yd22/XDcAIWg4+Q6T60RGFkFLOJHLlcEwQpCrEbVm 3Rx9vcvdk5O1QzzeC2JsJnX5oH4s52dQyTlvUchJad1AYvahSyOH7ojG+5e0IjLP79up rCGg== X-Gm-Message-State: AOAM532bATK98cFuRQe8U00T+bD4PKvyPsyt+7MDdi8R6QS/T2svcIxA +OPuDSaeifyijMm94o05iD50AmDL2vOBND8iuOs= X-Google-Smtp-Source: ABdhPJwxJ1ziKzyOl3573nGIPj8e6+HgoujTJyuoWVoCsgb4k1KlBmYXuAhiuarFpdBO8D/IDBdaSVVQrCPO/VAsGbg= X-Received: by 2002:ac8:5cc7:0:b0:2f3:bab2:92a8 with SMTP id s7-20020ac85cc7000000b002f3bab292a8mr14539246qta.224.1652696556831; Mon, 16 May 2022 03:22:36 -0700 (PDT) MIME-Version: 1.0 References: <97c39ec3-33f-36e1-ebd7-498e3772c9a3@ispras.ru> <245cc396-ad40-cb98-b171-e56e3d9c1c2@ispras.ru> <69142cd0-1947-e7d3-50ad-d9010f46fbf0@suse.cz> In-Reply-To: From: Richard Biener Date: Mon, 16 May 2022 12:22:24 +0200 Message-ID: Subject: Re: [PATCH] lto-plugin: add support for feature detection To: Jan Hubicka Cc: =?UTF-8?Q?Martin_Li=C5=A1ka?= , Alexander Monakov , GCC Patches Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, KAM_SHORT, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, 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 10:22:39 -0000 On Mon, May 16, 2022 at 11:50 AM Jan Hubicka wrote: > > > 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. Yep. Or if the docs are not too extensive pasting them into plugin-api.h itself might be not the worst idea either ... basically provide markup that doxygen or similar tools can re-create sth like the wiki page? Richard. > Honza > > > > Martin > > > > > > > > Honza > > >> > > >> Richard. > >