-
Bug
-
Resolution: Done
-
Normal
-
None
-
rhel-9.0.0
-
None
-
None
-
rhel-sst-pt-perf-debug
-
ssg_platform_tools
-
1
-
False
-
-
None
-
None
-
None
-
None
-
If docs needed, set a value
-
-
aarch64
-
None
Description of problem:
[1]: the address(with the p command) of schedule_hrtimeout_range() are different from the result of nm or objdump tool.
(gdb) p schedule_hrtimeout_range
$1 =
0xffff800010c0fd30 <schedule_hrtimeout_range>
^^^^^^^^^^^^^^^^^^
[root@ampere-mtsnow-altra-01-vm-07]# nm -nl /home/vmlinux |grep schedule_hrtimeout_range
ffff800010c0fd24 T schedule_hrtimeout_range /usr/src/debug/kernel-5.14.0-39.el9/linux-5.14.0-39.el9.aarch64/kernel/time/hrtimer.c:2313
^^^^^^^^^^^^^^^^
[root@ampere-mtsnow-altra-01-vm-07]# objdump -DS /home/vmlinux > vmlinux.log
[root@ampere-mtsnow-altra-01-vm-07]# strings vmlinux.log |grep schedule_hrtimeout_range
...
ffff800010c0fd24 <schedule_hrtimeout_range>:
^^^^^^^^^^^^^^^^
...
Obviously, the objdump and nm get the same addresss: 0xffff800010c0fd24, but the gdb prints the address: 0xffff800010c0fd30
[2] the l command prints incorrect source code
(gdb) l freezer_write
73
74 extern char *strim(char *);
75
76 static inline __must_check char *strstrip(char *str)
77
80
81 #ifndef __HAVE_ARCH_STRSTR
82 extern char * strstr(const char *, const char *);
(gdb) p freezer_write
$1 = {ssize_t (struct kernfs_open_file *, char *, size_t, loff_t)} 0xffff80001019a83c <freezer_write>
(gdb) list *0xffff80001019a83c
0xffff80001019a83c is in freezer_write (./include/linux/string.h:78).
73
74 extern char *strim(char *);
75
76 static inline __must_check char *strstrip(char *str)
77 {78 return strim(str);79 }
80
81 #ifndef __HAVE_ARCH_STRSTR
82 extern char * strstr(const char *, const char *);
(gdb)
Version-Release number of selected component (if applicable):
kernel-5.14.0-39.el9
gdb-10.2-9.el9
How reproducible:
Always
Steps to Reproduce:
1. gdb /usr/lib/debug/usr/lib/modules/5.14.0-39.el9.aarch64/vmlinux
2. l freezer_write
3.
Actual results:
Expected results:
Additional info:
I didn't see the same issue on x86_64 with the gdb-10.2, and it can not be reproduced on rhel8 kernel. For more details, see another bz2036872.
- external trackers