Fix get_func_ip for --filter-trace-tc

[Asphaltt]

Fix #293 .

bpf_get_func_ip() is supported since 5.15 kernel.

• bpf: Add bpf_get_func_ip helper for tracing programs

As a result, we have to figure out a way to avoid bpf_get_func_ip().

Then, I realise that something in /proc/kallsyms may help.

ffffffffc0024020 t bpf_prog_a04f5eef06a7f555_dummy	[bpf]
ffffffffc0024094 t bpf_prog_a04f5eef06a7f555_dummy	[bpf]
ffffffffc002ac4c t bpf_prog_0b3a2ce7164b50f3_fentry_tc	[bpf]
ffffffffc002add0 t bpf_prog_0ca2b1941f84fe9b_fexit_tc	[bpf]

Next, read the kernel source code.

• bpf_prog_ksym_set_name()

So, the bpf prog info in /proc/kallsyms maybe formats with ADDR t bpf_prog_<tag>_<name>\t[bpf].

Finally, I figure out the solution:

1. Record tag to ADDR in a map.
2. Get tag from bpf prog info.
3. Write tag's ADDR to bpf code.

Great! And optimise the outputing name of bpf prog BTW.

[Asphaltt]

bpf prog tag is not unique

Yes, the tag is not unique. bpf_prog_calc_tag

How about name -> addr instead of tag -> addr?

I think, it's to map addr -> name for bpf prog actually, no matter whether tag is unique.

[jschwinger233]

it's to map addr -> name for bpf prog actually, no matter whether tag is unique.

You are right, after all pwru will translate address to symbol name, so it doesn't have to be the precise address as long as the address is mapped to correct address.

[brb]

@Asphaltt :wave: Could you rebase your PR against the latest main branch? Also, does it still need a review?

[Asphaltt]

Yes, it's ready to review again.

[brb]

I'll approve it now, but want to bring this up: the event.addr may hold the wrong rip value, because two addresses could have one same symbol. As discussed before, that doesn't affect the symbol resolution because even a "wrong" rip can be matched to the right symbol. However, this could make a difference when we want to distinguish which exact bpf prog is called.

@Asphaltt maybe you could add this as a code comment?

[Asphaltt]

Sure.