From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-f174.google.com (mail-pl1-f174.google.com [209.85.214.174]) by sourceware.org (Postfix) with ESMTPS id 46E3E3858401 for ; Thu, 1 Sep 2022 07:42:31 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 46E3E3858401 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=maskray.me Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-pl1-f174.google.com with SMTP id y1so14478370plb.2 for ; Thu, 01 Sep 2022 00:42:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc; bh=saQBWllo6hCiT2H5q2Byx8sbxKAhqktXpXudySVe3Ys=; b=Rh5S0qIgNScqyPuQqq6YGvIIQfVPQIXRCp0LGoCX3SXnONZa++hEcKxZqR6utzfOyM 77PYYG13TbvtzRp/7nLq9j1NGYdGupsP0lKG8VHXjWRdzYsTSMBr2/qalGZSOSAYasbR D9SQvSN9i0PN26DfkVGKLCYa7Dvb3S/Mu0Han4M+WsHbw8xp1BGKB5lELViUPnt1F4o0 9dhkKi6TzBYhPPmlYWhmEMfy3pGV/b2L6585so7Vr/zgHDTUBeuLG9IJRltE3rdPm3A5 u9jtYfZkYE9Cple4XpUoyGzGLAGTcroWlMhTq8oUs9yA0oVZMpXvECkUwbLZUlSMJ+MG LMrg== X-Gm-Message-State: ACgBeo0+484jtaiWGIruPAK3Rv8q5oLodd+/Qii91z9L8s7tir7HucLa PVG+foXUSxkuT/uyCOUyxM8= X-Google-Smtp-Source: AA6agR7iOsHuHemIDSE1KQiHGrp3W3mf/AmwJ8aUciEoD3+Y+JwlDcvCjgh5yhVWv3OBsKfUE1lY4Q== X-Received: by 2002:a17:902:864c:b0:172:bc0d:c769 with SMTP id y12-20020a170902864c00b00172bc0dc769mr29596490plt.146.1662018149959; Thu, 01 Sep 2022 00:42:29 -0700 (PDT) Received: from localhost ([2601:647:6300:b760:ddd1:cf19:aee6:d49c]) by smtp.gmail.com with ESMTPSA id x18-20020aa78f12000000b0053788e9f865sm12477347pfr.21.2022.09.01.00.42.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 01 Sep 2022 00:42:29 -0700 (PDT) Date: Thu, 1 Sep 2022 00:42:28 -0700 From: Fangrui Song To: Xi Ruoyao Cc: liuzhensong , binutils@sourceware.org, chenglulu@loongson.cn Subject: Re: [PATCH] LoongArch: Use copy relocation for %pc_lo12 against external symbol Message-ID: <20220901074228.pofoyuc6346dlumu@gmail.com> References: <20220831132259.71417-1-xry111@xry111.site> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-1.6 required=5.0 tests=BAYES_00,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS,KAM_DMARC_STATUS,KAM_INFOUSMEBIZ,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 2022-09-01, Xi Ruoyao via Binutils wrote: >On Thu, 2022-09-01 at 09:27 +0800, liuzhensong wrote: > >> The R_LARCH_COPY is supported in older versions, we removed this >> feature and are not going to support. > >Hmm, then for > >extern int x; >int f() { return x; } > >it will produce a GOT access. If x is in another TU but not in a shared >library, such a GOT access and the GOT entry is unneeded. > >This will be really a pain for situations like building an OS kernel, or >with -static or -static-pie. Even for this simple example, there is no >way to tell "x" is not in a shared library (maybe, expect LTO or linker >relaxation, but IIRC LTO or relaxation do not *guarantee* to avoid the >GOT, just "try to" avoid the GOT). > >So is there any serious reason forbidding us from using R_LARCH_COPY? Or >any options for this "unneeded GOT" issue? >-- >Xi Ruoyao >School of Aerospace Science and Technology, Xidian University There is a slow trend to eliminate copy relocations for ELF platforms. If a new port doesn't have copy relocations, leave it. An architecture can add GOT indirection to PC-relative addressing optimization if desired.