From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-vs1-xe34.google.com (mail-vs1-xe34.google.com [IPv6:2607:f8b0:4864:20::e34]) by sourceware.org (Postfix) with ESMTPS id 482FE3858D3C for ; Thu, 5 May 2022 06:15:50 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 482FE3858D3C Received: by mail-vs1-xe34.google.com with SMTP id z144so3274008vsz.13 for ; Wed, 04 May 2022 23:15:50 -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=1o7SEQ1Ol5doD2CJNBlO2lvj47HDbScZPn5E1PKtM2s=; b=fJW+kjPXFWLtwj5bEqkbCYPSBnLC5HxSjkTGMiAqq4R8OzGewEXNaYSAAldXDa12tz 9r6APF2p4n4PW6/aivX7IJ6xvd80AzBEBt4SYMNXJDJjBifCuA2J3B7AShioFPPDbmdS ovpC3Wqt1TtDLE+zAmiyeX3XW1QUN51Ru0Wt2NO9mYieCUTO4iTAYzOgSC/lHxD/9aE3 ybZjRWYMqq5rvbzQXs2CzctKcDt55ymtrpAjBgQnx3bavEKyRbWq3+bto8jUIdt4JPKh 3YfFbH8NVp6d+xndcUqBdSM445WGTfZmfw6SBW0HquWZDZ4t75YJb3RABaYjXGEWmIhz W8Xg== X-Gm-Message-State: AOAM531TtWGfeFkE4y8hTb3Pw0/ujXOHr6tpCHI4kuRWrpS/2j17sJFv iczmDi+nktzsbVERN330W/6i4dMyogbKbGi27VA= X-Google-Smtp-Source: ABdhPJyne5FWiwdZW6YaOaBmyayd19umRasYp70i0EoU/iw2fv/YqDkmPEKkkrWX7/mA9c9kVscOhTlliM7g/D+W7ak= X-Received: by 2002:a67:67c6:0:b0:32c:bf27:8f68 with SMTP id b189-20020a6767c6000000b0032cbf278f68mr7496495vsc.86.1651731348198; Wed, 04 May 2022 23:15:48 -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:15:36 +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.3 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:15:54 -0000 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 proble= m this > > detection is solving, nor why this is the best way to solve that. Was t= here > > 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, more > > importantly, as 'v2 entrypoint will not be called'. > > Yes, if they register get_symbols_v3, then it will be called. That's how = 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 intermediately 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. Richard. > Martin > > > > > Alexander >