[BPF] Remove unused weak symbol __bpf_trap

[yonghong-song]

Nikita Popov reported an issue ([1]) where a dangling weak symbol __bpf_trap is in the final binary and this caused libbpf failing like below:

  $ veristat -v ./t.o
  Processing 't.o'...
  libbpf: elf: skipping unrecognized data section(4) .eh_frame
  libbpf: elf: skipping relo section(5) .rel.eh_frame for section(4) .eh_frame
  libbpf: failed to find BTF for extern '__bpf_trap': -3
  Failed to open './t.o': -3

In llvm, the dag selection phase generates __bpf_trap in code. Later the UnreachableBlockElim pass removed __bpf_trap from the code, but __bpf_trap symbol survives in the symbol table.

Having a dangling __bpf_trap weak symbol is not good for old kernels as seen in the above veristat failure. Although users could use compiler flag -mllvm -bpf-disable-trap-unreachable to workaround the issue, this patch fixed the issue by removing the dangling __bpf_trap.

[1] #165696

[github-actions]

✅ With the latest revision this PR passed the C/C++ code formatter.

[nikic]

cc @tuliom Would be good to confirm whether this fixes the issues you saw on RHEL 8.

[rupprecht]

This will always fire an assertion:

  MCSymbol *getMCSymbol() const {
    assert(isMCSymbol() && "Wrong MachineOperand accessor");
    return Contents.Sym;
  }

But isMCSymbol() is always false since isSymbol() is true instead.

What's the right fix?

[yonghong-song]

I used Op.isSymbol() as a possible target but running bpf selftest, the branch with Op.isSymbol() never to be true, at least when running linux kernel bpf selftests.

Let me double check whether this branch isSymbol() is really necessary or not.

[yonghong-song]

The BPF_TRAP is created as

  Function::Create(FT, GlobalValue::ExternalWeakLinkage, BPF_TRAP, M);

So BPF_TRAP will be used as a global in instructions. So the branch

  else if (Op.isSymbol()) { ... }

should be considered as dead code and can be removed.

WDYT?

[tuliom]

cc @tuliom Would be good to confirm whether this fixes the issues you saw on RHEL 8.

For the record: I've just confirmed this commit did solve #165696.

Thanks!