Re:Re: Re: [PATCH v7 2/2] selftests/bpf: Force -O2 for USDT selftests to cover SIB handling logic

[赵佳炜 <phoenix500526@163.com>]

Ok, I see. I file an issue in libbpf repo to track this discussion. 

FYI: https://github.com/libbpf/libbpf/issues/918








At 2025-08-22 02:28:31, "Andrii Nakryiko" <andrii.nakryiko@gmail.com> wrote:
>On Thu, Aug 21, 2025 at 8:38 AM 赵佳炜 <phoenix500526@163.com> wrote:
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> In the previous discussion with Yonghong Song, we found that some compiler would generate
>> such an arguement format. Although I have never encounter such an issue, I found that the
>> global volatile variable could trigger the compiler to generate this argument spec. So I tried to
>> solve this problem. I guess this would not be a problem since we have already used STAP_PROBE_ASM
>> to reliably generate SIB argument spec.
>
>Yep, let's hold off on implementing this, as it doesn't seem to be
>really necessary in practice.
>
>>
>> BTW, I have another issue to discuss.
>>
>> Now, bcc framework is not a recommendation for writing bpf program, so bpftrace is now migrating
>> from bcc framework to libbpf. Bcc framework provides some relevant APIs for get usdt probe info[1].
>> And I found that there is not similar APIs in libbpf, therefore I have to parse elf file manually.
>>
>> Could we add some relevant APIs, maybe like `bpf_program__usdt_probe_list`, in libbpf? I can make
>> a patch to implement it. WDYT?
>>
>
>I'm not yet convinced this belongs in libbpf, tbh. The process of
>discovering USDTs actually involved two separate tasks: discovering
>binaries (executable and shared libs) that constitute a process, and
>then for each binary discovering which USDTs belong to it. The first
>part is pretty clearly out of scope for libbpf. Second one in
>principle can be added, but as I said I'm a bit hesitant at this
>point, as we don't even have "USDT manager" exposed through public
>API.
>
>So not yet.
>
>>
>> [1]. https://github.com/bpftrace/bpftrace/blob/1cd4bbdd4a13dd55880f2cc638dde641fb5f8474/src/usdt.cpp#L131C1-L152C2
>>
>>
>>
>>
>>
>>
>>
>> At 2025-08-21 07:00:35, "Andrii Nakryiko" <andrii.nakryiko@gmail.com> wrote:
>> >On Mon, Aug 18, 2025 at 10:35 AM Yonghong Song <yonghong.song@linux.dev> wrote:
>> >>
>> >>
>> >>
>> >> On 8/17/25 6:43 AM, 赵佳炜 wrote:
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > Hi, Yonghong. I've already filed an issue[1] in GCC  community.
>> >> >
>> >> >
>> >> > Accroding to the discussion, it's not a gcc bug but may be a systemtap bug.
>> >> > I don't know how to report this bug to systemtap, but I found that the
>> >> > libbpf/usdt have the same problem. I've filed an issue in libbpf/usdt repo[2].
>> >> >
>> >> > I also have some ideas about it. I wrote it down in the issue[2] comment.
>> >> > May be we can discuss there.
>> >> >
>> >> > [1]. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121569
>> >> > [2]. https://github.com/libbpf/usdt/issues/13
>> >>
>> >> Thanks for filing an issue on gcc and getting some feedback/suggestions
>> >> from gcc community.
>> >>
>> >> Currently, libbpf/usdt does not suport format like '-1@ti(%rip)'. If we do
>> >
>> >Exactly, it doesn't. I haven't yet ran into a case where real-world
>> >applications would use such an argument format, so there was no
>> >incentive in trying to support it.
>> >
>> >Was this issue discovered as part of testing on some real world
>> >application, or it's mostly through testing on synthetic cases?
>> >
>> >> intend to implement this. libbpf/usdt can reject that if 'ti' is a
>> >> static variable. libbpf can provide some hints about how to make it
>> >> work (see above [1] and [2]). Then, it would be user's reponsibility to
>> >> change code so libbpf can support it.
>> >>
>> >> >
>> >> >
>> >> >
>> >
>> >[...]