From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <amonakov@ispras.ru>
Received: from mail.ispras.ru (mail.ispras.ru [83.149.199.84])
 by sourceware.org (Postfix) with ESMTPS id D84A938582BA
 for <gcc-patches@gcc.gnu.org>; Fri,  8 Jul 2022 12:41:14 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org D84A938582BA
Received: from [10.10.3.121] (unknown [10.10.3.121])
 by mail.ispras.ru (Postfix) with ESMTPS id 16FC940D4004;
 Fri,  8 Jul 2022 12:41:06 +0000 (UTC)
Date: Fri, 8 Jul 2022 15:41:06 +0300 (MSK)
From: Alexander Monakov <amonakov@ispras.ru>
To: =?ISO-8859-15?Q?Martin_Li=A8ka?= <mliska@suse.cz>
cc: Rui Ueyama <rui314@gmail.com>, Richard Biener <richard.guenther@gmail.com>,
 GCC Patches <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH 3/3] lto-plugin: implement LDPT_GET_API_VERSION
In-Reply-To: <e5e84d3c-777c-0367-f575-62801526c506@suse.cz>
Message-ID: <b0e6b1bd-1735-347-5a4b-3e7b40fa41bf@ispras.ru>
References: <803a0290-3909-b9c5-2461-b1740a00c63a@suse.cz>
 <bb9bf388-21d7-80d8-8474-6453fae50a49@suse.cz>
 <146a46f1-3a56-48c5-386f-c15633cc6781@ispras.ru>
 <37b52d36-d1dd-f291-0baa-0cf670493692@suse.cz>
 <CAFiYyc0AZSH5AuKo+fEj0doA+i77O+egK8ArugYbBM=nJBGcxQ@mail.gmail.com>
 <4e3df681-9523-4781-d324-9a6e230f495a@suse.cz>
 <CACKH++YcJ=fA-hC-R_=G9DV0C1ZJifPSh7wZ3rcFXZtMXqRgtw@mail.gmail.com>
 <3dc13790-a22d-c4d6-6cfe-ab9b567968ff@suse.cz>
 <CAFiYyc3C5tgM-rgZbRhF53eBKsERifiYuuab6FhC1AqSb-JvSA@mail.gmail.com>
 <b71724de-6511-8965-7132-c84d4e6b33a8@suse.cz>
 <CACKH++bkVcKSP5=0-1wBxJXO5OVW4GdMYg2ouYjDTZsUeccn9g@mail.gmail.com>
 <e5e84d3c-777c-0367-f575-62801526c506@suse.cz>
MIME-Version: 1.0
X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS,
 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
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8BIT
X-Content-Filtered-By: Mailman/MimeDel 2.1.29
X-BeenThere: gcc-patches@gcc.gnu.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Gcc-patches mailing list <gcc-patches.gcc.gnu.org>
List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-patches>,
 <mailto:gcc-patches-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <https://gcc.gnu.org/pipermail/gcc-patches/>
List-Post: <mailto:gcc-patches@gcc.gnu.org>
List-Help: <mailto:gcc-patches-request@gcc.gnu.org?subject=help>
List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-patches>,
 <mailto:gcc-patches-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Fri, 08 Jul 2022 12:41:16 -0000


On Fri, 8 Jul 2022, Martin Liška wrote:

> Hi.
> 
> All right, there's updated version of the patch that reflects the following suggestions:
> 
> 1) strings are used for version identification
> 2) thread-safe API version (1) is not used if target does not support locking via pthreads
> 
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
> 
> Ready to be installed?

Note that mold side will need to be adjusted, because it did not really
implement the proposed contract. Maybe we should be more clear how the
linker is supposed to implement this? Preliminary mold patch does this:

static PluginLinkerAPIVersion
get_api_version(const char *plugin_identifier,
                unsigned plugin_version,
                PluginLinkerAPIVersion minimal_api_supported,
                PluginLinkerAPIVersion maximal_api_supported,
                const char **linker_identifier,
                unsigned *linker_version) {
  assert(maximal_api_supported >= LAPI_V1);
  *linker_identifier = "mold";
  *linker_version = get_mold_version();
  is_gcc_linker_api_v1 = true;
  return LAPI_V1;
}

but ignoring min_api_supported is wrong, and assuming max_api_supported > 0
is also wrong. It really should check how given [min; max] range intersects
with its own range of supported versions.

Alexande