From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) by sourceware.org (Postfix) with ESMTPS id A88B9385E447 for ; Tue, 8 Jun 2021 23:23:21 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org A88B9385E447 Received: by mail-lf1-x130.google.com with SMTP id w33so34838413lfu.7 for ; Tue, 08 Jun 2021 16:23:21 -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:content-transfer-encoding; bh=y05BgSUNRKtQgGVFWHoDe7i62qxD+Ta6n7N8OVyaJiU=; b=F0wXb5I9iFTterp8iG8GPNH8uP9rnUcedTSCCn++/wbZA2Sf6qrI8Hj/be/Do0dk3Q rbLfiRiCL1HuyaqFycpjVPfA9umgJfBTtX6c97TjfkpZCuMnN/OoYJ4EtV6YJvCiWdOg rWkqSp5LCLgBCxtfrqQLX0R6vWVkwvMi3yH4x74SnivedKmC8gvpmi8wBvPE3lbokvMS 7WB6YscrFBA8Bnarih5aa0rB5HTW2+k6tOhpO1hs0Rz3E4D1GK3zXAZ+wJGD9wlbtSxd L0jjDxiKgfTFnvMUvV/4EGy1WO/o8NerznQ4Iig7Y8uTlNvLPTHgyVonawER+fW+8Gzx wzMA== X-Gm-Message-State: AOAM532GeG2D4hvbAT/CDh+oSa/B58lQlEWMcJ8KB7GLbTptyuDqpzA3 9Xd0kldKlPwFQhYQIIj/JlO5PRJI+BB4OLF7WW1HXR+hHuk= X-Google-Smtp-Source: ABdhPJyUw+kJ4jnWo4JCOvJ07t1lB2a9G9VTzcZCQu6Lsclld4AoObXuNlk5kl9Dqq7b8yp+B/pWqfq8ifWO2bZNeO4= X-Received: by 2002:ac2:4649:: with SMTP id s9mr17832642lfo.540.1623194600355; Tue, 08 Jun 2021 16:23:20 -0700 (PDT) MIME-Version: 1.0 References: <20210525033314.3008878-1-yhs@fb.com> <20210525182948.4wk3kd7vrvgdr2lu@google.com> <4410f328-58ae-24e4-5e63-cfde6e891bf4@fb.com> <8abe01cb-da8f-514c-6b52-b92686a16662@fb.com> <20210608183205.l22q43hinv6lzb4h@ast-mbp.dhcp.thefacebook.com> In-Reply-To: From: Alexei Starovoitov Date: Tue, 8 Jun 2021 16:23:07 -0700 Message-ID: Subject: Re: [PATCH bpf-next v2] docs/bpf: add llvm_reloc.rst to explain llvm bpf relocations To: =?UTF-8?B?RsSBbmctcnXDrCBTw7JuZw==?= Cc: elfutils-devel@sourceware.org, Yonghong Song , bpf , Alexei Starovoitov , Andrii Nakryiko , Daniel Borkmann , Kernel Team , John Fastabend , Lorenz Bauer Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: elfutils-devel@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Elfutils-devel mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2021 23:23:23 -0000 On Tue, Jun 8, 2021 at 4:10 PM F=C4=81ng-ru=C3=AC S=C3=B2ng wrote: > > On Tue, Jun 8, 2021 at 11:32 AM Alexei Starovoitov > wrote: > > > > On Tue, Jun 08, 2021 at 09:33:28AM -0700, F=C4=81ng-ru=C3=AC S=C3=B2ng = wrote: > > > On Tue, Jun 8, 2021 at 8:49 AM Alexei Starovoitov > > > wrote: > > > > > > > > On Mon, Jun 7, 2021 at 10:51 PM F=C4=81ng-ru=C3=AC S=C3=B2ng wrote: > > > > > > > > > > You can rename R_BPF_64_64 to something more meaningful, e.g. R_B= PF_64_LDIMM64. > > > > > Then I am fine that such a relocation type applies inconsecutive = bytes. > > > > > > > > > > See below. Just change every occurrence of the old name in llvm-p= roject. > > > > > > > > No. We cannot rename them, because certain gnu tools resolve relos = by name > > > > and not by number. > > > > > > How do the GNU tools resolve relocations by name instead of by > > > relocation type number? > > > I don't think this should and can be supported. > > > > > > Most tools should do: > > > if (type =3D=3D R_BPF_64_64) do_something(); > > > > > > You are free to change them to > > > if (type =3D=3D R_BPF_64_LDIMM64) do_something(); > > > as long as R_BPF_64_LDIMM64 is defined as the number. > > > > If you're going to succeed convincing elfutils maintainers to change > > their whole design then we can realistically talk about renaming. > > As a homework try cloning elfutils.git then change the name in backends= /x86_64_reloc.def > > or bpf_reloc.def while keeping the numbers and observe how the standard= tools stop working. > > > > Also R_BPF_64_64 may not be the best name, but R_BPF_64_LDIMM64 is > > not a good name either. > > I used R_BPF_64_LDIMM64 as an example. Surely you could name it more > appropriately. > > > Most architectures avoid using instruction mnemonic > > in relo names. The relo name should describe what it does instead of in= sn > > it applies to. TLS, GOT, PLT, ABS are good suffixes to use. LDIMM64 - n= ot really. > > Instead of R_BPF_64_32 we could have used R_BPF_64_PC32, but not R_BPF_= 64_CALL32. > > Anyway it's too late to change. > > R_X86_64_PC32/R_X86_64_PLT32 are different. > Please see https://sourceware.org/pipermail/binutils/2020-April/000424.ht= ml > for why a dedicated branch relocation > is preferred for a branch instruction. > > > elfutils folks, > > BPF is adding new relocation types R_BPF_64_ABS64/R_BPF_64_ABS32 which > will can cause ongoing confusion with the existing > R_BPF_64_32/R_BPF_64_64. Not true. There is no confusion. Everything is clearly documented: https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/tree/Docum= entation/bpf/llvm_reloc.rst > Can you comment on why elfutils cannot rename R_BPF_64_32/R_BPF_64_64 > while keep R_BPF_64_32/R_BPF_64_64 as deprecated aliases for the new > names? To make it clear... we're not proposing to rename or deprecate them. That's Fang-Rui's suggestion that doesn't make sense to us due to overhead involved and backward compatibility issues it brings.