Thanks, I dug into the inline assembly route more. A hand-encoded BPF_PSEUDO_MAP_VALUE ldimm64 in verifier_arena.c can produce the right instruction bytes only with __imm_addr(arena), but that emits R_BPF_64_NODYLD32. The selftests libbpf/bpftool link step rejects that relocation type.
I also tried register, immediate, and memory constraints with raw bytes. Those either fail in the BPF backend address matching or NOP padding path, or lower to a normal R_BPF_64_64 load followed by an ALU add. The latter does not exercise arena_map_direct_value_addr() with off == arena_size; it tests a later ALU-add path instead. I also checked the legacy test_verifier route. It can express the raw insn directly, but it requires adding arena-specific map creation and mmap fixup plumbing to the legacy runner. That seems more intrusive and less aligned with new selftests than the small prog_tests raw-instruction test. So my current preference is still to keep the userspace raw-instruction test. If that sounds reasonable, I can send v3 with this rationale added to the commit message/changelog.
