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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.




[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux