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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <eb7a3ed.9723.198cd47d479.Coremail.phoenix500526@163.com>
Date: Thu, 21 Aug 2025 23:38:13 +0800 (CST)
From: 赵佳炜 <phoenix500526@....com>
To: "Andrii Nakryiko" <andrii.nakryiko@...il.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










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. 

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?


[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.
>>
>> >
>> >
>> >
>
>[...]