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=-2.6 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FSL_HELO_FAKE, MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=no 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 A2F621F8C7 for ; Tue, 13 Jul 2021 08:07:12 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 651E7394AC04 for ; Tue, 13 Jul 2021 08:07:11 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 651E7394AC04 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1626163631; bh=IzR9dOvnD0DecI6J+FX6T+bpJhO9lD8Yjw4iWXbnXJc=; h=Date:To:Subject:References:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=lUeFuv/3G0nfRQ7z6eeIG7TJNhBQHwkt5s6aqf4xBXKtGPLgrkwhMQNLtyALjQ1/R pdiDB/dW6yz1K+nb6wOZ7beXk9/at4nXgoo52bCxg0UgfUnJU2yeoq+Bk1IHoNBRos md/R1JyLD5gmxk0dSDAsWiP7kC16yCMO3DXyNQDc= Received: from mail-pl1-x633.google.com (mail-pl1-x633.google.com [IPv6:2607:f8b0:4864:20::633]) by sourceware.org (Postfix) with ESMTPS id 7D02A383A835 for ; Tue, 13 Jul 2021 08:06:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 7D02A383A835 Received: by mail-pl1-x633.google.com with SMTP id b12so7777647plh.10 for ; Tue, 13 Jul 2021 01:06:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=IzR9dOvnD0DecI6J+FX6T+bpJhO9lD8Yjw4iWXbnXJc=; b=q0LzNxIjXWFw7vA1Qa5/B6o3TlT6H2wJwBSHbCEiwgP+uKLdplGTV5RyduZ3cbCeBE Ke4LMpA5W3Rkadhn/qxVP8D5RI0wZm1dwFUoBAdYZHImP9FtizZtjszx8orxxi+op+MD X/ieAvvqbD8XjJ92n34W2Pei2h133IM4FFA1uQGJCd2W+gyKHyOI3PsGXuh+eaiyp893 ZO/irYdpy4XcaiiOdh5YN2kRgraUB0manv3Xn1g2AjoYbxjDQCwi08b5feKocRVkFujL R95a+Nu9hjgJcyDU2w0cWNJAcM/EF7X6V1RwVrG3smoj4WinQ4gA6lmzOlMj6nMp59df z9sw== X-Gm-Message-State: AOAM53361DGz/H5qqeF0rd8pb+W2vN7vcpqPJBVb0xD/gyxKaQ8PdXw1 wKxe9213UVa21v7dmHlYG/tiNA== X-Google-Smtp-Source: ABdhPJyGdNoXccVjuT9FE/y3KZrLNzApBXnR2V4iUy3p9+oLteHXRCNIL18yWol4bvUS/2scpIWhHg== X-Received: by 2002:a17:90a:bd94:: with SMTP id z20mr3255048pjr.214.1626163610299; Tue, 13 Jul 2021 01:06:50 -0700 (PDT) Received: from google.com ([2620:15c:2ce:200:cfd7:8f48:93b6:b713]) by smtp.gmail.com with ESMTPSA id d6sm19970581pgq.88.2021.07.13.01.06.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 13 Jul 2021 01:06:49 -0700 (PDT) Date: Tue, 13 Jul 2021 01:06:46 -0700 To: Carlos O'Donell Subject: Re: [PATCH] csu: Skip ARCH_SETUP_IREL if _dl_relocate_static_pie applied IRELATIVE relocations [BZ #27164] Message-ID: <20210713080646.3n3ycmh3p4d7ul3t@google.com> References: <20210708221032.955550-1-maskray@google.com> <8b8fb5c9-ce4e-b10e-95b1-0281f96894c0@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <8b8fb5c9-ce4e-b10e-95b1-0281f96894c0@redhat.com> 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: Fangrui Song via Libc-alpha Reply-To: Fangrui Song Cc: libc-alpha@sourceware.org Errors-To: libc-alpha-bounces+e=80x24.org@sourceware.org Sender: "Libc-alpha" On 2021-07-12, Carlos O'Donell wrote: >On 7/8/21 6:10 PM, Fangrui Song wrote: >> From: Siva Chandra Reddy >> >> For a static pie, _dl_relocate_static_pie applies IRELATIVE relocations >> so ARCH_SETUP_IREL should not apply relocations again. The code >> currently relies on ld -pie not defining >> __rela_iplt_start/__rela_iplt_end (they end up as 0 as unresolved >> undefined weak symbols). > >Correct, this is how PIE and static PIE were designed by HJ. > >> However, LLD defines __rela_iplt_start/__rela_iplt_end regardless of >> -no-pie or -pie, so in an LLD linked static pie, ARCH_SETUP_IREL would >> re-apply the relocations in the range of [__rela_iplt_start, >> __rela_iplt_end), causing a segfault. > >The reason this issue has been raised is that our joint downstream >users are unable to use lld on existing systems to compile and test >static PIE binaries. > >Ryan Houdek raised it on IRC, and I asked them to file a bug: >https://sourceware.org/bugzilla/show_bug.cgi?id=28066 > >The average downstream users may take anywhere from 12-18 months to >get a new glibc in their systems. > >If lld were to make the change today that would enable all downstream >users to be able to use lld to compile static PIE without needing to >get an updated glibc. > >>From such a perspective the lld change to match binutils enables the >feature for the most number of users the fastest. > >> Change _dl_relocate_static_pie to return an int, indicating whether the >> relocations have been applied. This makes the intention clearer and >> makes glibc buildable with LLD>=9.0 if we allow LLD at configure time. >> >> In addition, this enables a future simplification to GNU ld: we can drop >> a linker script difference between -no-pie and -pie. >> >> Co-authored-by: Fangrui Song > >I'm not inclined to accept this path. Not because I think the patch is >technically wrong, but because fixing lld enables it immediately for the >most number of users (making the patch moot). True, changing lld is the fastest. (I am not sure the word "fix" is appropriate because it isn't clear lld is doing wrong here. HJ's argument "he designed __rela_iplt_start that way" wasn't convincing. Static pie is new. I don't see why the old mechanism doesn't deserve a refresh. (It is not my own opinion that -static-pie/--no-dynamic-linker/-z dynamic-undefined-weak were not as elegant as they could be.)) A toolchain project can do some workaround for a libc if this choice makes a large community happy. However, I think it is important not to take it granted. It is inadequate to just dismiss toolchain developers' reasonable complaints. The libc should actively fix the issues so that the toolchain will not need to bear unneeded code in the future. I actually have contributed quite a few lld/ELF patches to work around glibc. For this one I just feel it is not right to just patch lld/ELF without fixing glibc.