Re: [PATCH bpf-next v2] docs/bpf: add llvm_reloc.rst to explain llvm bpf relocations

From: Alexei Starovoitov <alexei.starovoitov@gmail.com>
To: "Fāng-ruì Sòng" <maskray@google.com>
Cc: Yonghong Song <yhs@fb.com>, bpf <bpf@vger.kernel.org>,
	Alexei Starovoitov <ast@kernel.org>,
	Andrii Nakryiko <andrii@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Kernel Team <kernel-team@fb.com>,
	John Fastabend <john.fastabend@gmail.com>,
	Lorenz Bauer <lmb@cloudflare.com>
Subject: Re: [PATCH bpf-next v2] docs/bpf: add llvm_reloc.rst to explain llvm bpf relocations
Date: Tue, 8 Jun 2021 08:49:41 -0700	[thread overview]
Message-ID: <CAADnVQ+sD7ELvEwKf5Ui1dVkXPYEyjkwFxogxP5_4vrH3nMhPA@mail.gmail.com> (raw)
In-Reply-To: <CAFP8O3JeGtDMATPsnjhRO3Ru+Lap2uJSG_jYzWcK4AWeBtXquw@mail.gmail.com>

On Mon, Jun 7, 2021 at 10:51 PM Fāng-ruì Sòng <maskray@google.com> wrote:
>
> You can rename R_BPF_64_64 to something more meaningful, e.g. R_BPF_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-project.

No. We cannot rename them, because certain gnu tools resolve relos by name
and not by number.
The only thing we can do is to document why such a name was picked in
the first place.
Back then 64_64 meant that it applied to 64-bit field in 16-byte insn.
Whereas 64_32 meant that it applied to 32-bit field in 8-byte insn.
64_64 used to be called 64_MAPFD relo, but was renamed early enough
while we still had time to do such rename. Now backward compatibility
is more important than odd looking names.