From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ua1-x931.google.com (mail-ua1-x931.google.com [IPv6:2607:f8b0:4864:20::931]) by sourceware.org (Postfix) with ESMTPS id 79DE93858D3C for ; Thu, 5 May 2022 06:31:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 79DE93858D3C Received: by mail-ua1-x931.google.com with SMTP id i16so1325449uat.5 for ; Wed, 04 May 2022 23:31:39 -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=x2Ch4gtRtH8RFpUjDdONUbJi94PLHND33a6epXFiSbM=; b=sX3KZwxIPjMmprLvV/C1LbfdcvMAsHoTImUOX2jcjud3elBj0pNIQvTk95nsPO6vns gb40Ri9lx+V+EJoOWNssELDLRUT2ftt4TZz95bpH1bO0B1xGLMWhko9r40ZPPg/zwjFn XTqpuodjGiqmtC7LFFj8OC/3NaY+cXgbRTiyF0m9/h5n6fvRzD5AH02RQRyDQbzksaVJ w+dke3waG5Lcp5HdTkQJSjP5ADyMpLPCKP1JETyU7KMRs6eIdjl7GLtQhgUijeQdwCvP 2bZqtj1HfvHGy/B0wwpjDWjSuCr0K7FH6HhkTQ+MaP6YqSzBodueSZZtiEXchB7vL7xB dCkA== X-Gm-Message-State: AOAM533B0jQ1Ss6YLHvE8u6AWGKcj3lxpZdFakpF35QdwnbysQTqzchE hCT4+SOryxVM0TF4rfOysF/aETamibPGlFwgOGc= X-Google-Smtp-Source: ABdhPJyVjdSkismuBBoBIMp1bnz3k2PsYDqAqBzyyLPY8CdzXZT0vcgx/X3W+MYFvL55ws65p9gw+ipHHcSXJBduqcU= X-Received: by 2002:ab0:30ce:0:b0:362:7eb0:62b8 with SMTP id c14-20020ab030ce000000b003627eb062b8mr7527348uam.94.1651732297398; Wed, 04 May 2022 23:31:37 -0700 (PDT) MIME-Version: 1.0 References: <63633ead-aa7e-c424-9851-ac332ac13df3@suse.cz> <27841a42-baef-d53e-c601-ad265030854d@suse.cz> In-Reply-To: From: Richard Biener Date: Thu, 5 May 2022 08:31:25 +0200 Message-ID: Subject: Re: [PATCH] lto-plugin: add support for feature detection To: =?UTF-8?Q?Martin_Li=C5=A1ka?= Cc: Alexander Monakov , GCC Patches , Jan Hubicka Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.0 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.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 06:31:51 -0000 On Thu, May 5, 2022 at 8:15 AM Richard Biener wrote: > > On Wed, May 4, 2022 at 3:31 PM Martin Li=C5=A1ka wrote: > > > > On 5/4/22 15:10, Alexander Monakov wrote: > > > On Wed, 4 May 2022, Martin Li=C5=A1ka wrote: > > > > > >> On 5/4/22 14:32, Alexander Monakov wrote: > > >>> On Wed, 4 May 2022, Martin Li=C5=A1ka wrote: > > >>> > > >>>> The patch is a follow-up of the discussion we've got in: > > >>>> https://gcc.gnu.org/pipermail/gcc-patches/2022-May/593901.html > > >>>> > > >>>> Mold linker would appreciate knowing in advance if get_symbols_v3 = is supported > > >>>> by a GCC plug-in or not. > > > > > > Out of curiousity, I looked at mold, and I don't understand what prob= lem this > > > detection is solving, nor why this is the best way to solve that. Was= there > > > some discussion with mold author I should check out? > > > > Sure, please take a look at this issue: > > https://github.com/rui314/mold/issues/454#issuecomment-1116849458 > > > > > > > > Note that mold takes this not only as 'v3 API is supported', but, mor= e > > > importantly, as 'v2 entrypoint will not be called'. > > > > Yes, if they register get_symbols_v3, then it will be called. That's ho= w the > > plug-in works. > > 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 intermediate= ly > 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. Richard. > Richard. > > > Martin > > > > > > > > Alexander > >