From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi1-x22e.google.com (mail-oi1-x22e.google.com [IPv6:2607:f8b0:4864:20::22e]) by sourceware.org (Postfix) with ESMTPS id B93433858C56 for ; Mon, 16 May 2022 08:37:16 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org B93433858C56 Received: by mail-oi1-x22e.google.com with SMTP id q10so17769083oia.9 for ; Mon, 16 May 2022 01:37:16 -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; bh=6asfawGECM81NlwatVeVYKZ0xMFoGSS9TqBKmQSqVWw=; b=jY1fLU+d33BFt3QFcYbSsvNTQDL7/knaRGuVVZs1/GRbIuGzhjFZWkzF73glCmKB3q Ap2TJXKkRhvuZLb94RYG6dFe1uigkBKyqjN3fTiFKtv0FH5ccqV5SEZDOsYsFFqz/KDw SfihUGnukHvL5esXSlnUUQoanVGYyar18j9vA40maHkUp+R81tYap58cftaLiCt4++Qz 1z7TZRtpH38lGt9XxeoMwYoX2r3SasbvSDyxpK6fZAW50/im860fCSKGWxgHlhC5xLx/ 2mUMOd9DFGQrcF8h9HcDJRVn8yhTcDoUqWSwa7UlNrbRlRe6Zl2cIo+5hbrBm6OlGBof n2dA== X-Gm-Message-State: AOAM533PVRAE0iis7ilHNbDsy7+JmcKcXNyomYMm90OXbmqtpoHh9+P1 XEV1mMOd8X9IbAQidKv6XV3+P4dp+354la/TOaQ= X-Google-Smtp-Source: ABdhPJzhnIeqiq3MlBZW/+dj71+Qpf3KYfddnrxZ2kUKYa1Lc5XppVmaMTR2f1F7L+wxXufjhH8ZAPe83+pJreC3ebk= X-Received: by 2002:a05:6808:170b:b0:2fa:729a:a42e with SMTP id bc11-20020a056808170b00b002fa729aa42emr12728360oib.0.1652690236041; Mon, 16 May 2022 01:37:16 -0700 (PDT) MIME-Version: 1.0 References: <63633ead-aa7e-c424-9851-ac332ac13df3@suse.cz> <80f37f2-efdf-673-a8f4-69f2d5842ea2@ispras.ru> <9de185b3-914-8522-7eb-40b802d4651@ispras.ru> <7788e58e-ce41-d25b-eefe-5f9c966a2ff2@ispras.ru> <97c39ec3-33f-36e1-ebd7-498e3772c9a3@ispras.ru> <245cc396-ad40-cb98-b171-e56e3d9c1c2@ispras.ru> In-Reply-To: <245cc396-ad40-cb98-b171-e56e3d9c1c2@ispras.ru> From: Rui Ueyama Date: Mon, 16 May 2022 16:37:05 +0800 Message-ID: Subject: Re: [PATCH] lto-plugin: add support for feature detection To: Alexander Monakov Cc: =?UTF-8?Q?Martin_Li=C5=A1ka?= , GCC Patches , Jan Hubicka Content-Type: text/plain; charset="UTF-8" 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 08:37:21 -0000 On Mon, May 16, 2022 at 2:38 PM Alexander Monakov wrote: > > On Mon, 16 May 2022, Rui Ueyama wrote: > > > If it is a guaranteed behavior that GCC of all versions that support > > only get_symbols_v2 don't leave a temporary file behind if it is > > suddenly disrupted during get_symbols_v2 execution, then yes, mold can > > restart itself when get_symbols_v2 is called for the first time. > > > > Is this what you want? I'm fine with that approach if it is guaranteed > > to work by GCC developers. > > I cannot answer that, hopefully someone in Cc: will. This sub-thread started > with Richard proposing an alternative solution for API level discovery [1] > (invoking onload twice, first with only the _v3 entrypoint in the "transfer > vector"), and then suggesting an onload_v2 variant that would allow to > discover which entrypoints the plugin is going to use [2]. > > [1] https://gcc.gnu.org/pipermail/gcc-patches/2022-May/594058.html > [2] https://gcc.gnu.org/pipermail/gcc-patches/2022-May/594059.html > > ... at which point I butted in, because the whole _v3 thing was shrouded in > mystery. Hopefully, now it makes more sense. > > > From my side I want to add that thread-safety remains a major unsolved point. > Compiler driver _always_ adds the plugin to linker command line, so I expect > that if you add a mutex around your claim_file hook invocation, you'll find > that it serializes the linker too much. Have you given some thought to that? > Will you be needing a plugin API upgrade to discover thread-safe entrypoints, > or do you have another solution in mind? >From my linker's point of view, the easiest way to handle the situation is to implement a logic like this: if (gcc_version >= 12.2) assume that claim_file_hook is thread safe else assume that claim_file_hook is not thread safe And that is also _very_ useful to identify the existence of get_symbols_v3, because we can do the same thing with s/12.2/12.1/.