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