From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x1035.google.com (mail-pj1-x1035.google.com [IPv6:2607:f8b0:4864:20::1035]) by sourceware.org (Postfix) with ESMTPS id D02F13856DC0 for ; Tue, 31 May 2022 07:42:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org D02F13856DC0 Received: by mail-pj1-x1035.google.com with SMTP id w2-20020a17090ac98200b001e0519fe5a8so1485293pjt.4 for ; Tue, 31 May 2022 00:42:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=8GUj2FDLIB5pUqngxz0+mBdBBoxfuvQrRUp/bjmIgUk=; b=5wWjR9DYBcLnc7aglKNyDyA1+eO824x+LMwCxj8cEr7/D5e8BYilOxT2VsvQiizAZJ L1OrBeCJNyJ5X6mig6idL331Cf+ypiJPzUcKS5FBvXd1bUEysIbvw3i4Wwlu2mBJo/x6 HhwEA+hX8qv8+Ld/TZZvaijyEI1eiBL3TlwuPqJBqPeTv46WuNtvNVd8FjnhOMkekEd3 MXq2rln66BpanKiW/61iCIkk5eZfLtIrGB2iLgfsyDYIBco/nsBdHXexNipP4aQL6meg IEEZA64OIRjBQPl5fDdphltaPH8RCvWE3QYZcX5kJIwtkbFY2UsdB2qo3y4ZYaXPq1FS UXbg== X-Gm-Message-State: AOAM533L542XjtUJzpQSzc3eJXlFLof7h3WALuMpEidA1gg1uMAdBpxy C/i7fG4lFQu6zYaiLXrhOVqjSg== X-Google-Smtp-Source: ABdhPJz0vkbGfjNeS8ToNhQAzr5jZcX9TJlMi5uFBFxiJqr5OuLVBRyzTrdVr76H1vUm7t6ZMV4iWA== X-Received: by 2002:a17:902:d70e:b0:162:1e73:55ea with SMTP id w14-20020a170902d70e00b001621e7355eamr44187838ply.36.1653982961702; Tue, 31 May 2022 00:42:41 -0700 (PDT) Received: from google.com ([2620:15c:2ce:200:fb0a:168d:1d08:ca3]) by smtp.gmail.com with ESMTPSA id cx17-20020a17090afd9100b001dcf49d92a1sm1073837pjb.28.2022.05.31.00.42.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 31 May 2022 00:42:41 -0700 (PDT) Date: Tue, 31 May 2022 00:42:37 -0700 From: Fangrui Song To: Wilco Dijkstra Cc: Florian Weimer , Szabolcs Nagy , Wilco Dijkstra via Libc-alpha Subject: Re: [PATCH 2/3] Revert "[AArch64][BZ #17711] Fix extern protected data handling" Message-ID: <20220531074237.2ttjnsxyivww7ygu@google.com> References: <87mtf5wk0k.fsf@oldenburg.str.redhat.com> <8735gwhz9i.fsf@oldenburg.str.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Spam-Status: No, score=-19.5 required=5.0 tests=BAYES_00, DKIMWL_WL_MED, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH, KAM_INFOUSMEBIZ, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE, USER_IN_DEF_DKIM_WL, USER_IN_DEF_SPF_WL autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org 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: , X-List-Received-Date: Tue, 31 May 2022 07:42:44 -0000 On 2022-05-26, Wilco Dijkstra via Libc-alpha wrote: >Hi Florian, > >Sure, something basic like this shows the issues: > >int x; >int f(void) { return ++x; } >int main(void) { return f(); } > >compile with -O2 -fPIC -flto -shared: > >00000000000004f0 : > 4f0:   b0000090        adrp    x16, 11000 <__cxa_finalize@GLIBC_2.17> > 4f4:   f9400611        ldr     x17, [x16, #8] > 4f8:   91002210        add     x16, x16, #0x8 > 4fc:   d61f0220        br      x17 > >0000000000000510
: > 510:   17fffff8        b       4f0 > >0000000000000600 : > 600:   90000081        adrp    x1, 10000 <__FRAME_END__+0xf8f8> > 604:   f947e821        ldr     x1, [x1, #4048] > 608:   b9400020        ldr     w0, [x1] > 60c:   11000400        add     w0, w0, #0x1 > 610:   b9000020        str     w0, [x1] > 614:   d65f03c0        ret > >So f() does not get inlined into main, it is redirected via PLT, and it uses a GOT >indirection to access the global. The underlying problem is that ELF assumes by >default that you want interposition/export for all symbols. In reality that is >almost never needed. > >LLVM makes -fno-semantic-interposition the default, >which solves the PLT and inlining issue, but not the unnecessary GOT indirections. LLVM/Clang's behavior is more complex, but stating "-fno-semantic-interposition the default" is incorrect. See https://maskray.me/blog/2021-05-09-fno-semantic-interposition#clang--fno-semantic-interposition https://fedoraproject.org/wiki/Changes/PythonNoSemanticInterpositionSpeedup#Detailed_Description used to be incorrect, and I sent them the updates we can see today.