From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS17314 8.43.84.0/22 X-Spam-Status: No, score=-4.1 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id A82561F910 for ; Thu, 17 Nov 2022 16:08:48 +0000 (UTC) Authentication-Results: dcvr.yhbt.net; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.b="Z6kZW9K5"; dkim-atps=neutral Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 8C7AE3AA900E for ; Thu, 17 Nov 2022 16:08:46 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 8C7AE3AA900E DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1668701326; bh=i1ZlWMBx/wpq6wTDMPtKaF71/sMhJffTJgMGtCiom9o=; h=References:In-Reply-To:Date:Subject:To:Cc:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=Z6kZW9K5Sw6CouXFSyAtD8synyrM06JjERcwu5oPSuT8N9mxqip6pcwBnTDx+NfcP koM2Fc0B3BeBSBYTYid6WuDrKm+5d6nE4gx6NwjO60Y5OWm6HsOHBdHL/5pqpS3hff NfhQWAoeG3znBcHADxUtY0alL/PzB2kNkHuqdyWE= Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [IPv6:2a00:1450:4864:20::534]) by sourceware.org (Postfix) with ESMTPS id 2226339960FC for ; Thu, 17 Nov 2022 16:08:26 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 2226339960FC Received: by mail-ed1-x534.google.com with SMTP id x2so3241594edd.2 for ; Thu, 17 Nov 2022 08:08:26 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=i1ZlWMBx/wpq6wTDMPtKaF71/sMhJffTJgMGtCiom9o=; b=f4K6IafN4kHL986Xd5eJgHJEA+vlMTIInBQilLghkElEmEXd0vizbMDXNoftYsd8ct spyQqCRoJ0sUHhQTh4EVHfwng0Cb+ISfRZ+SrFJDQZlK5VEf3nUAC1fP8HRq0JPzBkE6 1fLYrHgm221SuMr6603QO7TyOzGxd5HZpMuqDApmS1oC/STVX5MNW9KrZNNZGh+Pr6AU zSu0b7Efw+5WDPfwEcfChysCY1+N0xHcSzuHrgCp78xXAivlgMAnF8qnTMMOxVi9tN4j e8NcIGPmzIQmWAJHcDlRmiLDcsOTivzbymgwNwCx/B2Ht6HBuHy3Ki7suqB2tgSkGIXx DkpQ== X-Gm-Message-State: ANoB5plupI9yJHr9rZvqzzR30/RvjFOTVIgUwmt0euXYxwZYcTHxsgW3 r9xQCVyXeIPZkZtGuN/7Why4RzsHb3ZkHlLhFNk= X-Google-Smtp-Source: AA0mqf4zEBXcyprblfVjd2a6NIf0b5SvIpeNP1qejjjg42Ek/nn0ovF+ffUtmQnkx9SLYJ6Ai3vAD5BymcQDP1HoPQ8= X-Received: by 2002:aa7:cd1a:0:b0:459:f897:7940 with SMTP id b26-20020aa7cd1a000000b00459f8977940mr2690212edw.168.1668701304650; Thu, 17 Nov 2022 08:08:24 -0800 (PST) MIME-Version: 1.0 References: <20221117124317.2816607-1-adhemerval.zanella@linaro.org> In-Reply-To: <20221117124317.2816607-1-adhemerval.zanella@linaro.org> Date: Thu, 17 Nov 2022 08:07:45 -0800 Message-ID: Subject: Re: [PATCH] i386: Avoid avoid rely on linker optimization to avoid relocation To: Adhemerval Zanella Cc: libc-alpha@sourceware.org, Fangrui Song Content-Type: text/plain; charset="UTF-8" X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: "H.J. Lu via Libc-alpha" Reply-To: "H.J. Lu" Errors-To: libc-alpha-bounces+e=80x24.org@sourceware.org Sender: "Libc-alpha" On Thu, Nov 17, 2022 at 4:43 AM Adhemerval Zanella wrote: > > lld does not implement all the linker optimization to avoid the GOT > relocation as done by binutils (bfd/elf32-i386.c:elf_i386_convert_load_reloc). > The current 'movl main@GOT(%ebx), %eax' will then create a GOT > relocation when building with lld, which make static-pie status to > not being able to start the provided main function. > > The change uses a __wrap_main local symbol, which in turn calls main > (similar as used by aarch64 and s390x). > > Checked on i686-linux-gnu with binutils and lld. > --- > sysdeps/i386/start.S | 13 +++++++++---- > 1 file changed, 9 insertions(+), 4 deletions(-) > > diff --git a/sysdeps/i386/start.S b/sysdeps/i386/start.S > index 4ec04bdfd7..d593c4de00 100644 > --- a/sysdeps/i386/start.S > +++ b/sysdeps/i386/start.S > @@ -98,11 +98,10 @@ ENTRY (_start) > pushl main@GOT(%ebx) > # else > /* Avoid relocation in static PIE since _start is called before > - it is relocated. Don't use "leal main@GOTOFF(%ebx), %eax" > - since main may be in a shared object. Linker will convert > - "movl main@GOT(%ebx), %eax" to "leal main@GOTOFF(%ebx), %eax" > + it is relocated. This also avoid rely on linker optimization to > + transform 'movl main@GOT(%ebx), %eax' to 'leal main@GOTOFF(%ebx)' > if main is defined locally. */ > - movl main@GOT(%ebx), %eax > + leal __wrap_main@GOTOFF(%ebx), %eax > pushl %eax > # endif > > @@ -130,6 +129,12 @@ ENTRY (_start) > 1: movl (%esp), %ebx > ret > #endif > + > +#if defined PIC && !defined SHARED > +__wrap_main: > + _CET_ENDBR > + jmp main Shouldn't it be "jmp main@PLT"? > +#endif > END (_start) > > /* To fulfill the System V/i386 ABI we need this symbol. Yuck, it's so > -- > 2.34.1 > -- H.J.