Or maybe we can just throw an error when LOCAL symbols are duplicated. WDYT?
At 2025-08-10 16:55:38, "赵佳炜" <[email protected]> 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" <[email protected]> wrote:
>>
>>
>>On 8/6/25 7:57 PM, 赵佳炜 wrote:
>>>
>>>
>>>
>>> Hi Yonghong,
>>>
>>> I noticed that the USDT argument specification generated by GCC 14 is
>>> '8@array(,%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@array(,%rax,8)' may appear in CI environment.
>>
>>>
>>>
>>> At 2025-08-07 02:17:34, "Yonghong Song" <[email protected]> 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@4+t1(%rip)".
>>>>>
>>>>> In this patch:
>>>>> - add usdt_o2 test case to cover SIB addressing usdt argument spec
>>>>> handling logic
>>>>>
>>>>> Signed-off-by: Jiawei Zhao <[email protected]>
>>>>> ---
>>>>> 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@array(,%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.
>>>>
>>[...]
