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: AS3215 2.6.0.0/16 X-Spam-Status: No, score=-4.2 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 [IPv6:2620:52:3:1:0:246e:9693:128c]) (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 E3BFA1F8C6 for ; Tue, 13 Jul 2021 23:21:30 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 1A4F3393A003 for ; Tue, 13 Jul 2021 23:21:30 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 1A4F3393A003 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1626218490; bh=dC9ntngYddFwdBl8E+ufUEB3++tn3+tOtAOgqGCEkmU=; h=References:In-Reply-To:Date:Subject:To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=eKp13USTvQ5x+A/P01tCspC57GYECux1aMjnSKeAFNMK8t4goI6ysfQKt7FpNi8Zq Jalqw1ujIEDo8291YoEOvZMzwhw0cO8uLfGHorJc7+QBndOFYOumDNI0mRcdvGYNnN 8EeEx0RrxR7hDhyN89I6GqOEKSX9Q766NGq/e8OU= Received: from mail-oi1-x231.google.com (mail-oi1-x231.google.com [IPv6:2607:f8b0:4864:20::231]) by sourceware.org (Postfix) with ESMTPS id C43063858C3B for ; Tue, 13 Jul 2021 23:21:10 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org C43063858C3B Received: by mail-oi1-x231.google.com with SMTP id q16so200745oiw.6 for ; Tue, 13 Jul 2021 16:21:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=dC9ntngYddFwdBl8E+ufUEB3++tn3+tOtAOgqGCEkmU=; b=TMKh7wjnZU9Ixt/USi4g0H+DEzee3UG363VnnWkDZfHAgBYlR7ieY+eMdYbgdJBHD/ JNK2FeEwa9++KRYup8GHzZxQsCmw0cbpu8CQfkz3rKHE+mu5O5jTr8b0nZ5lafH4xdPx ME9jvDZhruAe2IUQcg3TzojfKgMTl7A+OwynHHQfFOQWRFEnRK/LGUUpsolhcZJ9khGp wvf1EIlIJ3vVxwmpwT1e6wj7vs/TJvncV545XkI5GpGgB5p6kCvhJkx/YJd7JpigC6Gq cQ+5mfYNmvk4nFa4W9JweQ08G8FV+fp8/YT06HFn4BxSqx1m5z1TMCFuoI+6Ygg5U18P kPlQ== X-Gm-Message-State: AOAM531YKPQlfbJtW+iCoK57yjwLjRPL5gDh67SxYn1Tvs3XrnDfYFzV R1a0B1F1abdbzDoepzY1uOH9DXy7Z5XyABEBAjE= X-Google-Smtp-Source: ABdhPJwPblJgaL7Ah7sAxM07kR+0zrKJjaiMsRGVeXZqvXaj/K2W1DSFvCCoLUZWURuZ5gZhW/K3NQotmQpwBfUxpbE= X-Received: by 2002:a05:6808:1388:: with SMTP id c8mr523728oiw.17.1626218470209; Tue, 13 Jul 2021 16:21:10 -0700 (PDT) MIME-Version: 1.0 References: <20210708221032.955550-1-maskray@google.com> <8b8fb5c9-ce4e-b10e-95b1-0281f96894c0@redhat.com> <20210713080646.3n3ycmh3p4d7ul3t@google.com> <11b630ce-8d50-ee07-37e9-b5fec16a6f18@gotplt.org> <20210713230639.mkyiijn6v7tlo7fc@google.com> In-Reply-To: <20210713230639.mkyiijn6v7tlo7fc@google.com> Date: Tue, 13 Jul 2021 16:20:34 -0700 Message-ID: Subject: Re: [PATCH] csu: Skip ARCH_SETUP_IREL if _dl_relocate_static_pie applied IRELATIVE relocations [BZ #27164] To: 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" Cc: GNU C Library Errors-To: libc-alpha-bounces+e=80x24.org@sourceware.org Sender: "Libc-alpha" On Tue, Jul 13, 2021 at 4:07 PM Fangrui Song via Libc-alpha wrote: > > On 2021-07-13, Siddhesh Poyarekar wrote: > >On 7/13/21 1:36 PM, Fangrui Song via Libc-alpha wrote: > >>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. > > > >What's the utility of having the __rela_iplt{_start,_end} symbols in > >all binaries other than, maybe, simplifying the static linker > >implementation? How does it improve things for the generated > >application code in the end? AFAICT it is doing the opposite by > >requiring application startup to add a conditional to work around the > >presence of a redundant symbol. > > > >Siddhesh > > Please see the sentence from the first message > "In addition, this enables a future simplification to GNU ld: we can > drop a linker script difference between -no-pie and -pie." Did you mean non-PIE static and PIE static? Neither PIE nor PDE define __rela_iplt{_start,_end}. > This is the only difference other than image base difference. There are many differences between non-PIE static and PIE static. Non-PIE static doesn't have DT_XXX sections. -- H.J.