Message-ID: <CAEf4BzZLMp5oLnF_Nfjru7+zE2P4981GXWGf6d=6jEY4TqBt4Q@mail.gmail.com>
Date: Thu, 21 Aug 2025 11:28:31 -0700
From: Andrii Nakryiko <andrii.nakryiko@...il.com>
To: 赵佳炜 <phoenix500526@....com>
Cc: Yonghong Song <yonghong.song@...ux.dev>, ast@...nel.org, daniel@...earbox.net, 
	andrii@...nel.org, bpf@...r.kernel.org, linux-kselftest@...r.kernel.org, 
	linux-kernel@...r.kernel.org
Subject: Re: Re: [PATCH v7 2/2] selftests/bpf: Force -O2 for USDT selftests to
 cover SIB handling logic

On Thu, Aug 21, 2025 at 8:38 AM 赵佳炜 <phoenix500526@....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@...il.com> wrote:
> >On Mon, Aug 18, 2025 at 10:35 AM Yonghong Song <yonghong.song@...ux.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.
> >>
> >> >
> >> >
> >> >
> >
> >[...]

Powered by blists - more mailing lists