linux-kernel - Re: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] [day] [month] [year] [list]
Message-ID: <1e56054f.1c86.1989359a77a.Coremail.phoenix500526@163.com>
Date: Sun, 10 Aug 2025 17:39:43 +0800 (CST)
From: 赵佳炜 <phoenix500526@....com>
To: "Yonghong Song" <yonghong.song@...ux.dev>
Cc: 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:Re: [PATCH v7 2/2] selftests/bpf: Force -O2 for USDT
 selftests to cover SIB handling logic










Or maybe we can just throw an error when LOCAL symbols are duplicated. WDYT?







At 2025-08-10 16:55:38, "赵佳炜" <phoenix500526@....com> wrote:
>
>
>
>Hi Yonghong,
>
>I found another issue where symbols can be duplicated, and I’m not sure how to tell them apart.
>
>For example, I created two C files named usdt_rip.c and hello.c. Both define their own static ti variables, like:`static volatile char ti = 0;`.
>
>After compiling, I obtained an ELF file usdt_rip whose .symtab contains the following entries:
>
>$ readelf -s usdt_rip
>
>Symbol table '.symtab' contains 42 entries:
>   Num:    Value          Size Type    Bind   Vis      Ndx Name
>     0: 0000000000000000     0 NOTYPE  LOCAL  DEFAULT  UND 
>     1: 0000000000000000     0 FILE    LOCAL  DEFAULT  ABS Scrt1.o
>     2: 000000000000038c    32 OBJECT  LOCAL  DEFAULT    4 __abi_tag
>     3: 0000000000000000     0 FILE    LOCAL  DEFAULT  ABS usdt_rip.c
>     4: 0000000000004021     1 OBJECT  LOCAL  DEFAULT   25 ti
>     5: 0000000000000000     0 FILE    LOCAL  DEFAULT  ABS crtstuff.c
>     6: 00000000000010a0     0 FUNC    LOCAL  DEFAULT   14 deregister_tm_clones
>     7: 00000000000010d0     0 FUNC    LOCAL  DEFAULT   14 register_tm_clones
>     8: 0000000000001110     0 FUNC    LOCAL  DEFAULT   14 __do_global_dtors_aux
>     9: 0000000000004020     1 OBJECT  LOCAL  DEFAULT   25 completed.0
>    10: 0000000000003df8     0 OBJECT  LOCAL  DEFAULT   21 __do_global_dtor[...]
>    11: 0000000000001150     0 FUNC    LOCAL  DEFAULT   14 frame_dummy
>    12: 0000000000003df0     0 OBJECT  LOCAL  DEFAULT   20 __frame_dummy_in[...]
>    13: 0000000000000000     0 FILE    LOCAL  DEFAULT  ABS damo.c
>    14: 0000000000004022     1 OBJECT  LOCAL  DEFAULT   25 ti
>    15: 0000000000000000     0 FILE    LOCAL  DEFAULT  ABS crtstuff.c
>    16: 00000000000020d8     0 OBJECT  LOCAL  DEFAULT   19 __FRAME_END__
>
>
>As you can see, there are two ti variables in the .symtab section. Their values are very close, making them hard to distinguish.
>
>I’m unsure how to handle this situation. Do you have any suggestions?
>
>Thanks,
>Jiawei Zhao
>
>
>
>
>
>
>
>
>
>At 2025-08-08 02:01:08, "Yonghong Song" <yonghong.song@...ux.dev> wrote:
>>
>>
>>On 8/6/25 7:57 PM, 赵佳炜 wrote:
>>>
>>>
>>>
>>> Hi Yonghong,
>>>
>>> I noticed that the USDT argument specification generated by GCC 14 is '8@...ay(,%rax,8)'.
>>> This pattern is currently not handled correctly. I'm exploring whether I can use DWARF information
>>> to calculate the address of this variable. This approach seems to work. However, since I can't
>>
>>I think 'array' should be in symbol table, so there is no need to check dwarf in my opinion.
>>
>>> reproduce the same issue on my machine, I plan to implement this approach for the PC-relative
>>> issue in a separate patch. Would that affect the merging of this patch?
>>
>>Let us handle this since '8@...ay(,%rax,8)' may appear in CI environment.
>>
>>>
>>>
>>> At 2025-08-07 02:17:34, "Yonghong Song" <yonghong.song@...ux.dev> wrote:
>>>>
>>>> On 8/6/25 2:24 AM, Jiawei Zhao 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@...1(%rip)".
>>>>>
>>>>> In this patch:
>>>>> - add usdt_o2 test case to cover SIB addressing usdt argument spec
>>>>>     handling logic
>>>>>
>>>>> Signed-off-by: Jiawei Zhao <phoenix500526@....com>
>>>>> ---
>>>>>    tools/testing/selftests/bpf/Makefile          |  8 +++
>>>>>    .../selftests/bpf/prog_tests/usdt_o2.c        | 71 +++++++++++++++++++
>>>>>    .../selftests/bpf/progs/test_usdt_o2.c        | 37 ++++++++++
>>>>>    3 files changed, 116 insertions(+)
>>>>>    create mode 100644 tools/testing/selftests/bpf/prog_tests/usdt_o2.c
>>>>>    create mode 100644 tools/testing/selftests/bpf/progs/test_usdt_o2.c
>>>>>
>>>>> diff --git a/tools/testing/selftests/bpf/Makefile b/tools/testing/selftests/bpf/Makefile
>>>>> index 910d8d6402ef..68cf6a9cf05f 100644
>>>>> --- a/tools/testing/selftests/bpf/Makefile
>>>>> +++ b/tools/testing/selftests/bpf/Makefile
>>>>> @@ -759,6 +759,14 @@ TRUNNER_BPF_BUILD_RULE := $$(error no BPF objects should be built)
>>>>>    TRUNNER_BPF_CFLAGS :=
>>>>>    $(eval $(call DEFINE_TEST_RUNNER,test_maps))
>>>>>    
>>>>> +# Use -O2 optimization to generate SIB addressing usdt argument spec
>>>>> +# Only apply on x86 architecture where SIB addressing is relevant
>>>>> +ifeq ($(ARCH), x86)
>>>>> +$(OUTPUT)/usdt_o2.test.o: CFLAGS:=$(subst O0,O2,$(CFLAGS))
>>>>> +$(OUTPUT)/cpuv4/usdt_o2.test.o: CFLAGS:=$(subst O0,O2,$(CFLAGS))
>>>>> +$(OUTPUT)/no_alu32/usdt_o2.test.o: CFLAGS:=$(subst O0,O2,$(CFLAGS))
>>>>> +endif
>>>> I tried your selftest with gcc14 and llvm20 in my environment. See below:
>>>>
>>>> llvm20:
>>>> Displaying notes found in: .note.stapsdt
>>>>    Owner                Data size        Description
>>>>    stapsdt              0x0000002f       NT_STAPSDT (SystemTap probe descriptors)
>>>>      Provider: test
>>>>      Name: usdt1
>>>>      Location: 0x00000000000003ac, Base: 0x0000000000000000, Semaphore: 0x0000000000000000
>>>>      Arguments: 8@-64(%rbp)
>>>>
>>>> gcc14:
>>>> Displaying notes found in: .note.stapsdt
>>>>    Owner                Data size        Description
>>>>    stapsdt              0x00000034       NT_STAPSDT (SystemTap probe descriptors)
>>>>      Provider: test
>>>>      Name: usdt1
>>>>      Location: 0x0000000000000334, Base: 0x0000000000000000, Semaphore: 0x0000000000000000
>>>>      Arguments: 8@...ay(,%rax,8)
>>>>
>>>> llvm20 and gcc14 generate different usdt patterns. '8@-64(%rbp)' already supports so
>>>> with SIB support, the test should pass CI, I think.
>>>>
>>[...]