[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <310495cd.19eb.19893314d03.Coremail.phoenix500526@163.com>
Date: Sun, 10 Aug 2025 16:55:38 +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: [PATCH v7 2/2] selftests/bpf: Force -O2 for USDT selftests
to cover SIB handling logic
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.
>>>
>[...]
Powered by blists - more mailing lists