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 = {int (ktime_t *, u64, const enum hrtimer_mode)} 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 { 78 return strim(str); 79 } 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.
(In reply to lijiang from comment #0) > [1]: the address(with the p command) of schedule_hrtimeout_range() are > different from the result of nm or objdump tool. > > Obviously, the objdump and nm get the same addresss: 0xffff800010c0fd24, but > the gdb prints the address: 0xffff800010c0fd30 `objdump' and `nm' display information about the ELF symbol. GDB, however, uses the debug information provided by the compiler. For this function, GDB sees: <1><1414412>: Abbrev Number: 116 (DW_TAG_subprogram) <1414413> DW_AT_external : 1 <1414413> DW_AT_name : (indirect string, offset: 0x157816): schedule_hrtimeout_range <1414417> DW_AT_decl_file : 2 <1414417> DW_AT_decl_line : 2347 <1414419> DW_AT_decl_column : 13 <141441a> DW_AT_prototyped : 1 <141441a> DW_AT_type : <0x14043c3> <141441e> DW_AT_inline : 1 (not inlined) <141441e> DW_AT_sibling : <0x141444a> [...] <1><14205e5>: Abbrev Number: 97 (DW_TAG_subprogram) <14205e6> DW_AT_abstract_origin: <0x1414412> <14205ea> DW_AT_low_pc : 0xffff800010c0fd30 <14205f2> DW_AT_high_pc : 0x20 <14205fa> DW_AT_frame_base : 1 byte block: 9c (DW_OP_call_frame_cfa) <14205fc> DW_AT_call_all_calls: 1 <14205fc> DW_AT_sibling : <0x1420650> This is where 0xffff800010c0fd30 comes from. To understand why, disassemble this symbol: $ objdump --disassemble=schedule_hrtimeout_range \ /usr/lib/debug/lib/modules/5.14.0-39.el9.aarch64/vmlinux /usr/lib/debug/lib/modules/5.14.0-39.el9.aarch64/vmlinux: file format elf64-littleaarch64 Disassembly of section .head.text: Disassembly of section .text: ffff800010c0fd24 <schedule_hrtimeout_range>: ffff800010c0fd24: d503245f bti c ffff800010c0fd28: d503201f nop ffff800010c0fd2c: d503201f nop ffff800010c0fd30: d503233f paciasp ffff800010c0fd34: a9bf7bfd stp x29, x30, [sp, #-16]! ffff800010c0fd38: 52800023 mov w3, #0x1 // #1 ffff800010c0fd3c: 910003fd mov x29, sp ffff800010c0fd40: 97ffffa9 bl ffff800010c0fbe4 <schedule_hrtimeout_range_clock> ffff800010c0fd44: a8c17bfd ldp x29, x30, [sp], #16 ffff800010c0fd48: d50323bf autiasp ffff800010c0fd4c: d65f03c0 ret Disassembly of section .init.text: Disassembly of section .exit.text: From the DIE describing the containing CU (hrtimer.c): <140430b> DW_AT_producer : (indirect string, offset: 0x1d0065): GNU C89 11.2.1 20211019 (Red Hat 11.2.1-6) -mlittle-endian -mgeneral-regs-only -mabi=lp 64 -mbranch-protection=pac-ret+leaf+bti -mstack-protector-guard=sysreg -mstack-p rotector-guard-reg=sp_el0 -mstack-protector-guard-offset=1960 -g -O2 -std=gnu90 -fno-strict-aliasing -fno-common -fshort-wchar -fno-PIE -fno-asynchronous-unwind -tables -fno-unwind-tables -fno-delete-null-pointer-checks -fno-allow-store-data -races -fstack-protector-strong -fno-omit-frame-pointer -fno-optimize-sibling-ca lls -fno-stack-clash-protection -fpatchable-function-entry=2 -fno-inline-functio ns-called-once -fno-strict-overflow -fstack-check=no -fconserve-stack You can see "-mbranch-protection=pac-ret+leaf+bti". So every function is prefaced with branch protection. These insns are /not/ included by GCC in the debuginfo This is why GCC/GDB say the function starts at a different address than the symbol's ELF address. > [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 { > 78 return strim(str); > 79 } > 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) A similar thing is happening here. What's compounding it, though, is that the very first instruction of the function is from an inlined function, and GDB currently doesn't handle that very well. There are several outstanding bugs against GDB about this, and several upstream attempts have been made to try and mitigate this, but compiler optimization is a very difficult thing to overcome. As for x86_64, the debuginfo coincides with the ELF symbol: [for the freezer_write case] <1><1aa564c>: Abbrev Number: 97 (DW_TAG_subprogram) <1aa564d> DW_AT_name : (indirect string, offset: 0x1c1aa6): freezer_write <1aa5651> DW_AT_decl_file : 1 <1aa5651> DW_AT_decl_line : 419 <1aa5653> DW_AT_decl_column : 16 <1aa5654> DW_AT_prototyped : 1 <1aa5654> DW_AT_type : <0x1a986bd> <1aa5658> DW_AT_low_pc : 0xffffffff811b8d00 <1aa5660> DW_AT_high_pc : 0x70 <1aa5668> DW_AT_frame_base : 1 byte block: 9c (DW_OP_call_frame_cfa) <1aa566a> DW_AT_call_all_calls: 1 <1aa566a> DW_AT_sibling : <0x1aa581e> $ nm /usr/lib/debug/lib/modules/5.14.0-43.el9.x86_64/vmlinux | grep freezer_write ffffffff811b8d00 t freezer_write $ objdump --disassemble=freezer_write \ /usr/lib/debug/lib/modules/5.14.0-43.el9.x86_64/vmlinux /usr/lib/debug/lib/modules/5.14.0-43.el9.x86_64/vmlinux: file format elf64-x86-64 Disassembly of section .text: ffffffff811b8d00 <freezer_write>: ffffffff811b8d00: e8 ab aa ea ff callq ffffffff810637b0 <__fentry__> ffffffff811b8d05: 41 55 push %r13 ffffffff811b8d07: 49 89 fd mov %rdi,%r13 ffffffff811b8d0a: 48 89 f7 mov %rsi,%rdi ffffffff811b8d0d: 41 54 push %r12 ffffffff811b8d0f: 55 push %rbp ffffffff811b8d10: 53 push %rbx [...] As you can see, this function (fortunately) does NOT start with an inlined function call, so GDB has no problem providing the real source listing. Unfortunately, I am not so sure there is much we can immediately do about this. Debugging optimized code is always "caveat emptor."
Thank you for the investigation and explanation, Keith. Let's keep an eye on upstream change. Thanks.