btf,info: Fix bad instruction offset when parsing infos from kernel

[dylandreimerink]

When BTF ext info is encoded in ELF the instruction offsets are in bytes, but when you pass them to the kernel they must be instruction indecies. Therefor we devide the offset by the instruction size in the parsing logic for ELF.

This was missed during the initial implementation of reading back BTF ext info from the kernel. This would cause an error when loading back ext info which was not a multiple of the instruction size or a bad instruction offset if it was.

This PR adds an argument to the parsing logic to specify where the ext info is being read from. It also adds LoadKernelLineInfos and LoadKernelFuncInfos to load the ext info from the kernel, using the correct direction enum internaly. These are now used by the info package.

Fixes: #1168

[lmb]

So how come this wasn't caught by tests? We don't have any non-zero offsets?

[dylandreimerink]

Yea, both of the test that could have caught this have very small programs where this doesn't surface:

=== RUN   TestProgInfoExtBTF
sched_process_exec:
         ; return 0;
        0: MovImm dst: r0 imm: 0
        1: Exit
        
 === RUN   TestProgramInstructions
test_prog:
        0: LdImmDW dst: r0 imm: -1
        2: Exit

Do we want a regression test for this?

[lmb]

Do we want a regression test for this?

That would be great!

[dylandreimerink]

I changed the TestProgInfoExtBTF test that was added in the original PR to test this feature. It now loads a more complex program with multiple line infos and func infos to verify that this feature works. Should be a better test.

[lmb]

@dylandreimerink super, thanks! I've pushed a fixup:

• I don't think we need the explicit LoadKernel.... My POV is that either we parse a full ELF, or we parse parts of the BTF from the kernel.
• I dislike bool arguments to functions but here it really makes the code easier to read.
• I simplified the test to not glob for the loader. There is no point in parsing the "wrong" endian files.

Let me know what you think!

[dylandreimerink]

Yes, all seem sensible! If we can get CI to agree that is. Shall I squash both commits?

[lmb]

Thanks, already done. Also adjusted the commit msg.