On Tue, Jun 8, 2021 at 8:49 AM Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> wrote: > > On Mon, Jun 7, 2021 at 10:51 PM Fāng-ruì Sòng <maskray@xxxxxxxxxx> 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. 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 == R_BPF_64_64) do_something(); You are free to change them to if (type == R_BPF_64_LDIMM64) do_something(); as long as R_BPF_64_LDIMM64 is defined as the 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.
