From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [IPv6:2a00:1450:4864:20::132]) by sourceware.org (Postfix) with ESMTPS id 52364382FDCA for ; Tue, 12 Jul 2022 01:36:35 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 52364382FDCA Received: by mail-lf1-x132.google.com with SMTP id u13so11535613lfn.5 for ; Mon, 11 Jul 2022 18:36:35 -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=B/6AyPYiWN3Jxv+dlz5N7SaN4r+utpbawE6Xxjfj2UA=; b=T7C5x/P8RGbAXYGzElLZlBjGk22tl7kgE7SBYDcXdAZS7AgXP+nL8LoRLzSDNRlAjd Y6XsB9jO5lCA+p3xj8jksHZaEZ1ryNJpvRVa6pwH/SG022NZQerGp0NN4JXpm1DDtfmw wfktSsfHwGmyrL5dJkD5JlPMceZshOQeYIryZpvDG2j8Y0RIMPgBswYo4eVyhZpk+kTr mUsHArko5eeuXket0GqyyM1Nv3GBAsMPoIgk7J+TUa5g+QtPPawyfBn6eEq/MY8KDehV lr05EYBug2AQz5fgC9iFLXWHdALv9gqyIhdu/TgAvKb7lcwKnUXJoeIk7lxYF/bxjESf cH2w== X-Gm-Message-State: AJIora+KayHVrHDNxDH4kz6v9TRHhGvezIHd09iBBowNEWzXy5Ogfe3o ZVjtI57Tytd9NY4WKw9b30ALFJ209K7Q/Eex1HI= X-Google-Smtp-Source: AGRyM1uxh+VSDsoioRXKL1+bCyvwxUv3ByzFvekjYoWrdPTIePzZK5lOGIwt9nqC3ivbfNj0Hq3dFWZ2KSvMr3Vjc38= X-Received: by 2002:a05:6512:22c6:b0:489:efee:f963 with SMTP id g6-20020a05651222c600b00489efeef963mr718126lfu.486.1657589793511; Mon, 11 Jul 2022 18:36:33 -0700 (PDT) MIME-Version: 1.0 References: <803a0290-3909-b9c5-2461-b1740a00c63a@suse.cz> <146a46f1-3a56-48c5-386f-c15633cc6781@ispras.ru> <37b52d36-d1dd-f291-0baa-0cf670493692@suse.cz> <4e3df681-9523-4781-d324-9a6e230f495a@suse.cz> <3dc13790-a22d-c4d6-6cfe-ab9b567968ff@suse.cz> <862b4381-c377-ac7a-476c-e7ced3c29c2c@ispras.ru> <3bde5aa4-f3d7-63e8-8b4f-29b29f00293f@suse.cz> <252fef4a-c9f6-5bb4-2ad4-690cb730b9d6@suse.cz> In-Reply-To: <252fef4a-c9f6-5bb4-2ad4-690cb730b9d6@suse.cz> From: Rui Ueyama Date: Tue, 12 Jul 2022 09:36:22 +0800 Message-ID: Subject: Re: [PATCH 3/3] lto-plugin: implement LDPT_GET_API_VERSION To: =?UTF-8?Q?Martin_Li=C5=A1ka?= Cc: Richard Biener , Alexander Monakov , GCC Patches Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-6.3 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_ENVFROM_END_DIGIT, FREEMAIL_FROM, GIT_PATCH_0, 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: Tue, 12 Jul 2022 01:36:37 -0000 I updated my code so that it now acquires a lock before calling claim_file if v0. https://github.com/rui314/mold/commit/54fedf005fb35acdcb0408395aa403f942621= 90a On Mon, Jul 11, 2022 at 8:51 PM Martin Li=C5=A1ka wrote: > > On 7/11/22 14:24, Rui Ueyama wrote: > > I updated my patch to support the proposed API: > > https://github.com/rui314/mold/commit/22bbfa9bba9beeaf40b76481d175939ee= 2c62ec8 > > > > Martin, > > > > I think you want to apply this patch. Currently, your API always > > passes LAPI_V0 as the maximum API version. > > Are you sure? > > The function signature is: > > (*ld_plugin_get_api_version) (const char *plugin_identifier, > const char *plugin_version, > enum linker_api_version minimal_api_supporte= d, > enum linker_api_version maximal_api_supporte= d, > ... > > Which means the plug-in always set minimal as LAPI_V0 and maximal > LAPI_V0/V1. That seems correct to me. I'm sorry I misunderstood your code. It looks correct. > Martin > > > > > > diff --git a/lto-plugin/lto-plugin.c b/lto-plugin/lto-plugin.c > > index e9afd2fb76d..c97bda9de91 100644 > > --- a/lto-plugin/lto-plugin.c > > +++ b/lto-plugin/lto-plugin.c > > @@ -1441,15 +1441,15 @@ negotiate_api_version (void) > > const char *linker_version; > > > > enum linker_api_version supported_api =3D LAPI_V0; > > #if HAVE_PTHREAD_LOCKING > > supported_api =3D LAPI_V1; > > #endif > > > > - api_version =3D get_api_version ("GCC", BASE_VERSION, LAPI_V0, > > + api_version =3D get_api_version ("GCC", BASE_VERSION, LAPI_V1, > > supported_api, &linker_identifier, > > &linker_version); > > if (api_version > supported_api) > > { > > fprintf (stderr, "requested an unsupported API version (%d)\n", > > api_version); > > abort (); > > } > > > > On Mon, Jul 11, 2022 at 6:51 PM Martin Li=C5=A1ka wrot= e: > >> > >> On 7/11/22 11:55, Richard Biener wrote: > >>> On Mon, Jul 11, 2022 at 11:16 AM Alexander Monakov wrote: > >>>> > >>>> On Mon, 11 Jul 2022, Rui Ueyama wrote: > >>>> > >>>>>> but ignoring min_api_supported is wrong, and assuming max_api_supp= orted > 0 > >>>>>> is also wrong. It really should check how given [min; max] range i= ntersects > >>>>>> with its own range of supported versions. > >>>>> > >>>>> Currently only one version is defined which is LAPI_V1. I don't thi= nk > >>>>> LAPI_UNSPECIFIED is a version number; rather, it's an unspecified > >>>>> value. No ordering should be defined between a defined value and an > >>>>> unspecified value. If LAPI_UNSPECIFIED < LAPI_V1, it should be rena= med > >>>>> LAPI_V0. > >>>> > >>>> You still cannot rely on API guarantees of LAPI_V1 when the plugin d= oes not > >>>> advertise it (thread safety of claim_file in this particular case). > >>> > >> > >> Hi. > >> > >> All right, I think we should rename LAPI_UNSPECIFIED to LAPI_V0 in ord= er > >> to support minimal_api_supported =3D=3D LAPI_V0. > >> > >>> So with LAPI_UNSPECIFIED all the plugin gets is the linker name and v= ersion. > >>> Clarifying the documentation on LAPI_UNSPECIFIED might be nice, also > >>> what the expectation is on the linker when the plugin returns > >>> LAPI_UNSPECIFIED when it speficied minimal_api_supported =3D=3D V1. > >> > >> I've clarified that linker should return a value that is in range > >> [minimal_api_supported, maximal_api_supported] and added an abort > >> if it's not the case. > >> > >> Having that, mold should respect if maximal_api_supported =3D=3D LAPI_= V0 is returned > >> by a plug-in (happens now as we miss locking for some targets). > >> > >> Martin > >> > >>> "minimal_api_supported =3D=3D LAPI_UNSPECIFIED" does not make much > >>> sense if using Ruis reading of this value? > >>> > >>>> And you still should check the intersection of supported API ranges > >>>> and give a sane diagnostic when min_api_supported advertised by the = plugin > >>>> exceeds LAPI_V1 (though, granted, the plugin could error out as well= in this > >>>> case). > >>>> > >>>> Alexander >