Provide some more hints to the user/developer when relos have been found that don't point to ld64 imm instruction. Ran couple of times into relos generated by clang [1], where the compiler tried to uninline inlined functions with eBPF and emitted BPF_JMP | BPF_CALL opcodes. If this seems the case, give a hint that the user should do a work-around to use always_inline annotation.
[1] https://llvm.org/bugs/show_bug.cgi?id=26243#c3 Signed-off-by: Daniel Borkmann <dan...@iogearbox.net> --- tc/tc_bpf.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/tc/tc_bpf.c b/tc/tc_bpf.c index a1286ba..5e80d0f 100644 --- a/tc/tc_bpf.c +++ b/tc/tc_bpf.c @@ -1385,8 +1385,16 @@ static int bpf_apply_relo_data(struct bpf_elf_ctx *ctx, ioff = relo.r_offset / sizeof(struct bpf_insn); if (ioff >= num_insns || - insns[ioff].code != (BPF_LD | BPF_IMM | BPF_DW)) + insns[ioff].code != (BPF_LD | BPF_IMM | BPF_DW)) { + fprintf(stderr, "ELF contains relo data for non ld64 " + "instruction at offset %u! Compiler bug?!\n", + ioff); + if (ioff < num_insns && + insns[ioff].code == (BPF_JMP | BPF_CALL)) + fprintf(stderr, " - Try to annotate functions " + "with always_inline attribute!\n"); return -EINVAL; + } if (gelf_getsym(ctx->sym_tab, GELF_R_SYM(relo.r_info), &sym) != &sym) return -EIO; -- 1.9.3
