linux-kselftest.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: 赵佳炜 <phoenix500526@163.com>
To: "Andrii Nakryiko" <andrii.nakryiko@gmail.com>
Cc: ast@kernel.org, daniel@iogearbox.net, andrii@kernel.org,
	yonghong.song@linux.dev, bpf@vger.kernel.org,
	linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re:Re: [PATCH bpf-next v13 2/2] selftests/bpf: Enrich subtest_basic_usdt case in selftests to cover SIB handling logic
Date: Sat, 23 Aug 2025 10:58:38 +0800 (CST)	[thread overview]
Message-ID: <530fff84.d87.198d4dd1fb8.Coremail.phoenix500526@163.com> (raw)
In-Reply-To: <CAEf4Bzbs3hV_Q47+d93tTX13WkrpkpOb4=U04mZCjHyZg4aVdw@mail.gmail.com>







>does clang define __GNUC__ as well? otherwise why !define(__clang__) ?

Yes, clang does defind __GNUC__ .



>you use assembly directly, so optimize() should be irrelevant, no?
>
>So we can make this non-GCC specific, right?

Yes, I'll make it in the next version.


>is it guaranteed that nums address will end up in rdx and a in rax?...
>
>I'd feel more comfortable if you explicitly set up rdx and rax in
>assembly, then add USDT with STAP_PROBE_ASM. That should be possible
>with embedded assembly, no?

I think it will in that the input operand constrain `"d"(nums), "a"(0)` implies
the nums address will end up in rdx while the index 0 will be in rax. 

So I think we don't need to explicitly set up rdx and rax again. 


>why these unnecessary comments embedded in the assembly?...

Because there is "before" and "after" in the `STAP_PROBE_ASM` example.
It's OK to remove it. 


At 2025-08-23 06:59:49, "Andrii Nakryiko" <andrii.nakryiko@gmail.com> wrote:
>On Fri, Aug 22, 2025 at 8:16 AM Jiawei Zhao <phoenix500526@163.com> wrote:
>>
>> When using GCC on x86-64 to compile an usdt prog with -O1 or higher
>> optimization, the compiler will generate SIB addressing mode for global
>> array and PC-relative addressing mode for global variable,
>> e.g. "1@-96(%rbp,%rax,8)" and "-1@4+t1(%rip)".
>>
>> In this patch:
>> - enrich subtest_basic_usdt test case to cover SIB addressing usdt argument spec
>>   handling logic
>>
>> Signed-off-by: Jiawei Zhao <phoenix500526@163.com>
>> ---
>>  tools/testing/selftests/bpf/prog_tests/usdt.c | 44 ++++++++++++++++++-
>>  tools/testing/selftests/bpf/progs/test_usdt.c | 30 +++++++++++++
>>  2 files changed, 72 insertions(+), 2 deletions(-)
>>
>> diff --git a/tools/testing/selftests/bpf/prog_tests/usdt.c b/tools/testing/selftests/bpf/prog_tests/usdt.c
>> index 9057e983cc54..c04b416aa4a8 100644
>> --- a/tools/testing/selftests/bpf/prog_tests/usdt.c
>> +++ b/tools/testing/selftests/bpf/prog_tests/usdt.c
>> @@ -25,6 +25,10 @@ unsigned short test_usdt0_semaphore SEC(".probes");
>>  unsigned short test_usdt3_semaphore SEC(".probes");
>>  unsigned short test_usdt12_semaphore SEC(".probes");
>>
>> +#if ((defined(__x86_64__) || defined(__i386__)) && defined(__GNUC__) && !defined(__clang__))
>
>does clang define __GNUC__ as well? otherwise why !define(__clang__) ?
>
>> +unsigned short test_usdt_sib_semaphore SEC(".probes");
>> +#endif
>> +
>>  static void __always_inline trigger_func(int x) {
>>         long y = 42;
>>
>> @@ -40,12 +44,29 @@ static void __always_inline trigger_func(int x) {
>>         }
>>  }
>>
>> +#if ((defined(__x86_64__) || defined(__i386__)) && defined(__GNUC__) && !defined(__clang__))
>> +static __attribute__((optimize("O1"))) void trigger_sib_spec(void)
>
>you use assembly directly, so optimize() should be irrelevant, no?
>
>So we can make this non-GCC specific, right?
>
>> +{
>> +       /* Base address + offset + (index * scale) */
>> +       /* Force SIB addressing with inline assembly */
>> +       asm volatile(
>> +               "# probe point with memory access\n"
>> +               STAP_PROBE_ASM(test, usdt_sib, -2@(%%rdx,%%rax,2))
>
>is it guaranteed that nums address will end up in rdx and a in rax?...
>
>I'd feel more comfortable if you explicitly set up rdx and rax in
>assembly, then add USDT with STAP_PROBE_ASM. That should be possible
>with embedded assembly, no?
>
>> +               "# end probe point"
>
>why these unnecessary comments embedded in the assembly?...
>
>> +               :
>> +               : "d"(nums), "a"(0)
>> +               : "memory"
>> +       );
>> +}
>
>[...]
>
>> +
>> +int usdt_sib_called;
>> +u64 usdt_sib_cookie;
>> +int usdt_sib_arg_cnt;
>> +int usdt_sib_arg_ret;
>> +u64 usdt_sib_arg;
>> +int usdt_sib_arg_size;
>> +
>> +// Note: usdt_sib is only tested on x86-related architectures, so it requires
>> +// manual attach since auto-attach will panic tests under other architectures
>
>don't use c++ style comments
>
>> +SEC("usdt")
>> +int usdt_sib(struct pt_regs *ctx)
>> +{
>> +       long tmp;
>> +
>> +       if (my_pid != (bpf_get_current_pid_tgid() >> 32))
>> +               return 0;
>> +
>> +       __sync_fetch_and_add(&usdt_sib_called, 1);
>> +
>> +       usdt_sib_cookie = bpf_usdt_cookie(ctx);
>> +       usdt_sib_arg_cnt = bpf_usdt_arg_cnt(ctx);
>> +
>> +       usdt_sib_arg_ret = bpf_usdt_arg(ctx, 0, &tmp);
>> +       usdt_sib_arg = (short)tmp;
>> +       usdt_sib_arg_size = bpf_usdt_arg_size(ctx, 0);
>> +
>> +       return 0;
>> +}
>> +
>>  char _license[] SEC("license") = "GPL";
>> --
>> 2.43.0
>>

  reply	other threads:[~2025-08-23  2:59 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-22 15:16 [PATCH bpf-next v13 0/2] libbpf: fix USDT SIB argument handling causing unrecognized register error Jiawei Zhao
2025-08-22 15:16 ` [PATCH bpf-next v13 1/2] " Jiawei Zhao
2025-08-22 22:43   ` Andrii Nakryiko
2025-08-23  3:29     ` 赵佳炜
2025-08-22 15:16 ` [PATCH bpf-next v13 2/2] selftests/bpf: Enrich subtest_basic_usdt case in selftests to cover SIB handling logic Jiawei Zhao
2025-08-22 22:59   ` Andrii Nakryiko
2025-08-23  2:58     ` 赵佳炜 [this message]
2025-08-23  3:51     ` 赵佳炜

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=530fff84.d87.198d4dd1fb8.Coremail.phoenix500526@163.com \
    --to=phoenix500526@163.com \
    --cc=andrii.nakryiko@gmail.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=yonghong.song@linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).