Thanks for diagnosing this!

• Does libbpf do the same write into R10 trick, or something different?
• Can you add a test?

P.S. The reason we don't adjust automatically for this is because the offset is encoded in the instruction stream. Does the jump instruction in the ELF carry a relocation to an LBB_ block? We strip those here:

Does libbpf do the same write into R10 trick, or something different?

I came up with this myself, I didn't think to look at libbpf's approach. They seem to emit 2 call instructions in this case:

if (res->poison) {
poison:
	/* poison second part of ldimm64 to avoid confusing error from
	 * verifier about "unknown opcode 00"
	 */
	if (is_ldimm64_insn(insn))
		bpf_core_poison_insn(prog_name, relo_idx, insn_idx + 1, insn + 1);
	bpf_core_poison_insn(prog_name, relo_idx, insn_idx, insn);
	return 0;
}

We could just copy that.

Can you add a test?

Yea, ofcourse.

Does the jump instruction in the ELF carry a relocation to an LBB_ block?

It does, but I think the current fix is good enough?

bpf_bpf.o:      file format elf64-bpf

Disassembly of section kprobe/tcp_close:

0000000000000000 <kprobe_tcp_close>:
       0:       18 01 00 00 01 00 00 00 00 00 00 00 00 00 00 00 r1 = 0x1 ll
       2:       15 01 03 00 00 00 00 00 if r1 == 0x0 goto +0x3 <LBB0_2>
       3:       18 01 00 00 01 00 00 00 00 00 00 00 00 00 00 00 r1 = 0x1 ll
       5:       63 1a fc ff 00 00 00 00 *(u32 *)(r10 - 0x4) = r1

0000000000000030 <LBB0_2>:
       6:       b7 00 00 00 00 00 00 00 r0 = 0x0
       7:       95 00 00 00 00 00 00 00 exit

We could just copy that.

Yeah let's do that. The call instruction is already confusing enough.

From discussion on Slack: going with the write to RFP trick, since that means we can avoid breaking API.