Or maybe we can just throw an error when LOCAL symbols are duplicated. WDYT?
At 2025-08-10 16:55:38, "赵佳炜" phoenix500526@163.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@linux.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@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" yonghong.song@linux.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@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 phoenix500526@163.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@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.
[...]