[PATCH] D101336: [LLD][BPF] Add bpf support

[Yonghong Song via Phabricator via llvm-commits]

yonghong-song added a comment.

Just updated the summary to include a link to bpf relocation documentation. Later on, once this is integrated into Linus tree (https://github.com/torvalds/linux), and built and placed in kernel/doc bpf relocation information should be very easily searchable (https://www.kernel.org/doc/html/latest/bpf/index.html).

Added Rui Ueyama (@ruiu), Rafael Espindola (@respindola) and George Rimar (@grimar) as reviewers too to get more perspective on how to move forward.

Currently, the patch is stuck as Fangrui (@MaskRay) really wants to rename some of bpf relocations, specifically R_BPF_64_64 and R_BPF_64_32.
See the detailed discussions here:

  https://lore.kernel.org/bpf/CAADnVQJa=b=hoMGU213wMxyZzycPEKjAPFArKNatbVe4FvzVUA@mail.gmail.com/T/#t

I completely agree that these names are not really good and not reflect what the underlying relocation is doing. See the above discussion. That is why we added bpf relocations into kernel doc so people can easily check and find out what these relocations are for. BTW, the idea to create a bpf relocation documentation is from
Fangrui.

But relocation names R_BPF_64_64 and R_BPF_64_32 has been in BPF community since Nov 2016 with commit

  7ab125dbf344 ([bpf] fix dwarf elf relocs and line numbers)

Before that there is only one relocation called R_BPF_MAP_FD. The renaming happens because bpf is still in its infant stage at that time and not many users.

Now bpf has a large community and R_BPF_64_64/R_BPF_64_32 is in elfutils and glibc_headers and libbpf and possibly other tools. Event the latest ebpf-for-windows mentioning these relocation names. From https://github.com/microsoft/ebpf-for-windows.git,

  $ egrep -r R_BPF
  docs/tutorial.md:0000000000000000 R_BPF_64_64 .data
  docs/tutorial.md:0000000000000040 R_BPF_64_64 map

Changing these names will confuse users as the `llvm-objdump -r` and `llvm-readobj -r` output will have different names than the code or *existing* documentation. I think having a ready documentation (https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/tree/Documentation/bpf/llvm_reloc.rst) should be a reasonable step if anybody wants to understand what the relocation intends to do. I think in most cases, for people cares the relocation implementation details, looking at names almost always not enough for any architecture, you need to look at the code or detailed documentations, at least for me.

It would be good if @ruiu, @respindola) and @grimar or any other people interested in discussion can share their perspective. Thanks!


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D101336/new/

https://reviews.llvm.org/D101336