From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi1-x235.google.com (mail-oi1-x235.google.com [IPv6:2607:f8b0:4864:20::235]) by sourceware.org (Postfix) with ESMTPS id 1253C3858C50 for ; Mon, 16 May 2022 10:44:54 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 1253C3858C50 Received: by mail-oi1-x235.google.com with SMTP id y63so18064410oia.7 for ; Mon, 16 May 2022 03:44:54 -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:content-transfer-encoding; bh=cfVW1aDDOtXMEIRY1HYcHDmFSE1/zake7k03n7zIsIg=; b=vuzkbICKen4hTDVTCv3Ws0P4OxnktDFjaoX0NOHYsa4nHA89kYfAUz9Nfv3+4XcHCM LPf9Gcw79ppCTZhxQ2L8CetWTUQHCtyFL2Bc9kkaeCBBYxcCqe8Vc+mpjWaPL7TD6Qyt Gkrp6ydL7L3LwomAS+PARfB6YK0CXZJpXQlUqT0mc8KtQER5b5w6MguBCpoYfMl0Ax8U cdzDTPfM9zH1LufbXt/POpci1ei6bgBKWMH4f71VczCYsU2WKdBEfx0/8G5KckuWiUcT doJKA7VRynA+ka4fVBxRdV6dchxqFEt2Wat4S0vSyvUniObiBbUTS3TmBPHaTsJwRvVa VMdw== X-Gm-Message-State: AOAM5328FZQzFPp/8hKwFvPEAKLgeaFjefYJej/pzyb92q63eRG4QGf5 udF9ZeHx0z0ZAjeOP1hJBc8xOS7idDLhUyGjpow= X-Google-Smtp-Source: ABdhPJy5Z6uMXZ5CRyfoidDu3UtV8rxCTg5UzbT2Tpisg3YGswUcfacZ7/W2WYxAulf6RjglJ6JtVN8Wh02O2UONKPw= X-Received: by 2002:a05:6808:170b:b0:2fa:729a:a42e with SMTP id bc11-20020a056808170b00b002fa729aa42emr12909241oib.0.1652697891857; Mon, 16 May 2022 03:44:51 -0700 (PDT) MIME-Version: 1.0 References: <7788e58e-ce41-d25b-eefe-5f9c966a2ff2@ispras.ru> <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: Rui Ueyama Date: Mon, 16 May 2022 18:44:40 +0800 Message-ID: Subject: Re: [PATCH] lto-plugin: add support for feature detection To: Richard Biener Cc: =?UTF-8?Q?Martin_Li=C5=A1ka?= , Jan Hubicka , Alexander Monakov , GCC Patches Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-0.6 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_ENVFROM_END_DIGIT, 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:44:56 -0000 On Mon, May 16, 2022 at 6:28 PM Richard Biener wrote: > > On Mon, May 16, 2022 at 11:58 AM Rui Ueyama wrote: > > > > Version handshaking is doable, but it feels like we are over-designing > > an API, given that the real providers of this plugin API are only GCC > > and LLVM and the users of the API are BFD ld, gold and mold. It is > > unlikely that we'll have dozens of more compilers or linkers in the > > near future. So, I personally prefer the following style > > > > if (!strcmp(plugin_compiler_name, "gcc") && plugin_major >=3D 12) > > > > than versioning various API-provided functions. It'll just work and be > > easy to understand. > > > > Besides that, even if we version GCC-provided plugin API functions, we > > still need a logic similar to the above to distinguish GCC from LLVM, > > as they behave slightly differently in various corner cases. We can't > > get rid of the heuristic version detection logic from the linker > > anyways. > > > > So, from the linker's point of view, exporting a compiler name and > > version numbers is enough. > > I agree that this might be convenient enough but the different behaviors > are because of inadequate documentation of the API - that's something > we should fix. And for this I think a plugin API version might help > as we can this way also handle your case of the need of querying > whether v2 will be used or not. > > I wouldn't go to enumerate past API versions - the version handshake > hook requirement alone makes that not so useful. Instead I'd require > everybody implementing the handshare hook implementing also all > other hooks defined at that point in time and set the version to 1. > > I'd eventually keep version 2 to indicate thread safety (of a part of the= API). > > That said, I'm not opposed to add a "GCC 12.1" provider, maybe the > version handshake should be > > int api_version (int linker, const char **identifier); > > where the linker specifies the desired API version and passes an > identifier identifying itself ("mold 1.0") and it will get back the API > version the plugin intends to use plus an identifier of the plugin > ("GCC 12.1"). void api_version(char *linker_identifier, const char **compiler_identifier, int *compiler_version); might be a bit better, where compiler_identifier is something like "gcc" or "clang" and comipler_version is 12001000 for 12.1.0. In the longer term, it feels to me that gcc should migrate to LLVM's libLTO-compatible API (https://llvm.org/docs/LinkTimeOptimization.html). It has resolved various problems of GCC's plugin API. A few notable examples are: - libLTO API separates a function to read a symbol table from an IR object from adding that object to the LTO final result - libLTO API functions don't depend on a global state of the plugin API, while GCC LTO plugin saves its internal state to a global variable (so we can't have two linker instances in a single process with GCC LTO, for example) - libLTO API doesn't use callbacks. It looks much more straightforward than GCC's plugin API. > Richard. > > > > > > > On Mon, May 16, 2022 at 5:38 PM Martin Li=C5=A1ka wrot= e: > > > > > > 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 com= piler' > > > >> is useful if bugs are discovered in old versions that you by defin= ition cannot > > > >> fix but can apply workarounds to. Note the actual compiler used m= ight 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_ve= rsion > > > >> hook which could also specify that with say version 2 the plugin w= ill > > > >> not use get_symbols_v2 but only newer, etc. The linker would anno= unce > > > >> 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 w= ay 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 solv= ing > > > > the file handler problems) > > > > > > How should be design such a version handshake? > > > > > > > > > > >> 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 si= nce > > > > 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. > > > > > > Martin > > > > > > > > > > > Honza > > > >> > > > >> Richard. > > >