What | Removed | Added |
---|---|---|
Flags | needinfo?(msuchanek@suse.com) | |
CC | msuchanek@suse.com |
Strange and I would need to take a look at sources because 000000000000abb0 <nv_register_procfs>: [...] adbc: e8 00 00 00 00 call adc1 <nv_register_procfs+0x211> adbd: R_X86_64_PC32 __stack_chk_fail-0x4 adc1: 4c 8b 05 00 00 00 00 mov 0x0(%rip),%r8 # adc8 <nv_register_procfs+0x218> adc4: R_X86_64_PC32 .bss+0x1284 adc8: 48 c7 c1 00 00 00 00 mov $0x0,%rcx adcb: R_X86_64_32S .rodata+0x420 adcf: 48 89 c2 mov %rax,%rdx add2: be 24 81 00 00 mov $0x8124,%esi add7: e8 00 00 00 00 call addc <nv_register_procfs+0x22c> add8: R_X86_64_PC32 proc_create_data-0x4 addc: 0f 1f 40 00 nopl 0x0(%rax) It really ends with a call to proc_create_data() which, obviously, is not a noreturn function. So it falls through to the next one. If it ended with the call to __stack_chk_fail() a couple of lines above, like most of the other functions, everything would be fine, because __stack_chk_fail() is marked as noreturn and objtool knows about it. The code between the call to __stack_chk_fail() and the call to proc_create_data() fills arguments. adc1 address is a target of intra-function jump so looks like a valid code. 000000000000ade0 <nv_unregister_procfs>: ade0: e8 00 00 00 00 call ade5 <nv_unregister_procfs+0x5> ade1: R_X86_64_PC32 __fentry__-0x4 ade5: 48 8b 3d 00 00 00 00 mov 0x0(%rip),%rdi # adec <nv_unregister_procfs+0xc> ade8: R_X86_64_PC32 .bss+0x1274 adec: e9 00 00 00 00 jmp adf1 <nv_unregister_procfs+0x11> aded: R_X86_64_PC32 proc_remove-0x4 adf1: 66 66 2e 0f 1f 84 00 data16 cs nopw 0x0(%rax,%rax,1) adf8: 00 00 00 00 adfc: 0f 1f 40 00 nopl 0x0(%rax) I left it here as an example. There is jmp at the end which is correct. It does not return. Sibling jump. All good. I am only guessing without sources though. Could you also appends logs from the compilation, please?