* [PATCH 02/10] x86: assembly, use ENDPROC for functions [not found] <20170217104757.28588-1-jslaby@suse.cz> @ 2017-02-17 10:47 ` Jiri Slaby 2017-02-17 11:08 ` Juergen Gross 2017-02-17 10:47 ` [PATCH 08/10] x86: assembly, annotate aliases Jiri Slaby ` (2 subsequent siblings) 3 siblings, 1 reply; 18+ messages in thread From: Jiri Slaby @ 2017-02-17 10:47 UTC (permalink / raw) To: mingo Cc: Juergen Gross, hpa, linux-pm, x86, Rafael J. Wysocki, linux-kernel, Pavel Machek, jpoimboe, xen-devel, tglx, Jiri Slaby, Boris Ostrovsky Somewhere END was used to end a function, elsewhere, nothing was used. So unify it and mark them all by ENDPROC. Signed-off-by: Jiri Slaby <jslaby@suse.cz> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@redhat.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: <x86@kernel.org> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net> Cc: Pavel Machek <pavel@ucw.cz> Cc: <linux-pm@vger.kernel.org> Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com> Cc: Juergen Gross <jgross@suse.com> Cc: <xen-devel@lists.xenproject.org> --- arch/x86/entry/entry_64.S | 40 ++++++++++++++++++------------------ arch/x86/entry/entry_64_compat.S | 4 ++-- arch/x86/kernel/mcount_64.S | 10 +++++---- arch/x86/power/hibernate_asm_64.S | 2 ++ arch/x86/realmode/rm/reboot.S | 1 + arch/x86/realmode/rm/trampoline_64.S | 4 ++++ arch/x86/realmode/rm/wakeup_asm.S | 1 + arch/x86/xen/xen-asm_64.S | 2 ++ arch/x86/xen/xen-head.S | 2 +- arch/x86/xen/xen-pvh.S | 2 +- 10 files changed, 40 insertions(+), 28 deletions(-) diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S index 044d18ebc43c..2f06104e2b5e 100644 --- a/arch/x86/entry/entry_64.S +++ b/arch/x86/entry/entry_64.S @@ -324,7 +324,7 @@ syscall_return_via_sysret: opportunistic_sysret_failed: SWAPGS jmp restore_c_regs_and_iret -END(entry_SYSCALL_64) +ENDPROC(entry_SYSCALL_64) ENTRY(stub_ptregs_64) /* @@ -350,13 +350,13 @@ ENTRY(stub_ptregs_64) 1: jmp *%rax /* Called from C */ -END(stub_ptregs_64) +ENDPROC(stub_ptregs_64) .macro ptregs_stub func ENTRY(ptregs_\func) leaq \func(%rip), %rax jmp stub_ptregs_64 -END(ptregs_\func) +ENDPROC(ptregs_\func) .endm /* Instantiate ptregs_stub for each ptregs-using syscall */ @@ -399,7 +399,7 @@ ENTRY(__switch_to_asm) popq %rbp jmp __switch_to -END(__switch_to_asm) +ENDPROC(__switch_to_asm) /* * A newly forked process directly context switches into this address. @@ -435,7 +435,7 @@ ENTRY(ret_from_fork) */ movq $0, RAX(%rsp) jmp 2b -END(ret_from_fork) +ENDPROC(ret_from_fork) /* * Build the entry stubs with some assembler magic. @@ -450,7 +450,7 @@ ENTRY(irq_entries_start) jmp common_interrupt .align 8 .endr -END(irq_entries_start) +ENDPROC(irq_entries_start) /* * Interrupt entry/exit. @@ -652,7 +652,7 @@ native_irq_return_ldt: */ jmp native_irq_return_iret #endif -END(common_interrupt) +ENDPROC(common_interrupt) /* * APIC interrupts. @@ -664,7 +664,7 @@ ENTRY(\sym) .Lcommon_\sym: interrupt \do_sym jmp ret_from_intr -END(\sym) +ENDPROC(\sym) .endm #ifdef CONFIG_TRACING @@ -830,7 +830,7 @@ ENTRY(\sym) jmp error_exit /* %ebx: no swapgs flag */ .endif -END(\sym) +ENDPROC(\sym) .endm #ifdef CONFIG_TRACING @@ -873,7 +873,7 @@ ENTRY(native_load_gs_index) SWAPGS popfq ret -END(native_load_gs_index) +ENDPROC(native_load_gs_index) EXPORT_SYMBOL(native_load_gs_index) _ASM_EXTABLE(.Lgs_change, bad_gs) @@ -903,7 +903,7 @@ ENTRY(do_softirq_own_stack) leaveq decl PER_CPU_VAR(irq_count) ret -END(do_softirq_own_stack) +ENDPROC(do_softirq_own_stack) #ifdef CONFIG_XEN idtentry xen_hypervisor_callback xen_do_hypervisor_callback has_error_code=0 @@ -939,7 +939,7 @@ ENTRY(xen_do_hypervisor_callback) /* do_hypervisor_callback(struct *pt_regs) */ call xen_maybe_preempt_hcall #endif jmp error_exit -END(xen_do_hypervisor_callback) +ENDPROC(xen_do_hypervisor_callback) /* * Hypervisor uses this for application faults while it executes. @@ -985,7 +985,7 @@ ENTRY(xen_failsafe_callback) SAVE_EXTRA_REGS ENCODE_FRAME_POINTER jmp error_exit -END(xen_failsafe_callback) +ENDPROC(xen_failsafe_callback) apicinterrupt3 HYPERVISOR_CALLBACK_VECTOR \ xen_hvm_callback_vector xen_evtchn_do_upcall @@ -1036,7 +1036,7 @@ ENTRY(paranoid_entry) SWAPGS xorl %ebx, %ebx 1: ret -END(paranoid_entry) +ENDPROC(paranoid_entry) /* * "Paranoid" exit path from exception stack. This is invoked @@ -1065,7 +1065,7 @@ paranoid_exit_restore: RESTORE_C_REGS REMOVE_PT_GPREGS_FROM_STACK 8 INTERRUPT_RETURN -END(paranoid_exit) +ENDPROC(paranoid_exit) /* * Save all registers in pt_regs, and switch gs if needed. @@ -1147,7 +1147,7 @@ ENTRY(error_entry) mov %rax, %rsp decl %ebx jmp .Lerror_entry_from_usermode_after_swapgs -END(error_entry) +ENDPROC(error_entry) /* @@ -1162,7 +1162,7 @@ ENTRY(error_exit) testl %eax, %eax jnz retint_kernel jmp retint_user -END(error_exit) +ENDPROC(error_exit) /* Runs on exception stack */ ENTRY(nmi) @@ -1510,12 +1510,12 @@ nmi_restore: * mode, so this cannot result in a fault. */ INTERRUPT_RETURN -END(nmi) +ENDPROC(nmi) ENTRY(ignore_sysret) mov $-ENOSYS, %eax sysret -END(ignore_sysret) +ENDPROC(ignore_sysret) ENTRY(rewind_stack_do_exit) /* Prevent any naive code from trying to unwind to our caller. */ @@ -1526,4 +1526,4 @@ ENTRY(rewind_stack_do_exit) call do_exit 1: jmp 1b -END(rewind_stack_do_exit) +ENDPROC(rewind_stack_do_exit) diff --git a/arch/x86/entry/entry_64_compat.S b/arch/x86/entry/entry_64_compat.S index e1721dafbcb1..966c09ffd62d 100644 --- a/arch/x86/entry/entry_64_compat.S +++ b/arch/x86/entry/entry_64_compat.S @@ -262,7 +262,7 @@ sysret32_from_system_call: movq RSP-ORIG_RAX(%rsp), %rsp swapgs sysretl -END(entry_SYSCALL_compat) +ENDPROC(entry_SYSCALL_compat) /* * 32-bit legacy system call entry. @@ -340,7 +340,7 @@ ENTRY(entry_INT80_compat) TRACE_IRQS_ON SWAPGS jmp restore_regs_and_iret -END(entry_INT80_compat) +ENDPROC(entry_INT80_compat) ALIGN GLOBAL(stub32_clone) diff --git a/arch/x86/kernel/mcount_64.S b/arch/x86/kernel/mcount_64.S index 3e35675e201e..5255c7888c50 100644 --- a/arch/x86/kernel/mcount_64.S +++ b/arch/x86/kernel/mcount_64.S @@ -145,7 +145,7 @@ ENTRY(fentry_hook) retq -END(fentry_hook) +ENDPROC(fentry_hook) ENTRY(ftrace_caller) /* save_mcount_regs fills in first two parameters */ @@ -177,6 +177,7 @@ GLOBAL(ftrace_epilogue) GLOBAL(ftrace_graph_call) jmp ftrace_stub #endif +ENDPROC(ftrace_caller) /* This is weak to keep gas from relaxing the jumps */ WEAK(ftrace_stub) @@ -252,7 +253,7 @@ GLOBAL(ftrace_regs_caller_end) jmp ftrace_epilogue -END(ftrace_regs_caller) +ENDPROC(ftrace_regs_caller) #else /* ! CONFIG_DYNAMIC_FTRACE */ @@ -288,7 +289,7 @@ trace: restore_mcount_regs jmp fgraph_trace -END(fentry_hook) +ENDPROC(fentry_hook) #endif /* CONFIG_DYNAMIC_FTRACE */ EXPORT_SYMBOL(fentry_hook) #endif /* CONFIG_FUNCTION_TRACER */ @@ -312,7 +313,7 @@ ENTRY(ftrace_graph_caller) restore_mcount_regs retq -END(ftrace_graph_caller) +ENDPROC(ftrace_graph_caller) ENTRY(return_to_handler) subq $24, %rsp @@ -329,4 +330,5 @@ ENTRY(return_to_handler) movq (%rsp), %rax addq $24, %rsp jmp *%rdi +ENDPROC(return_to_handler) #endif diff --git a/arch/x86/power/hibernate_asm_64.S b/arch/x86/power/hibernate_asm_64.S index ce8da3a0412c..ec6b26fd3a7e 100644 --- a/arch/x86/power/hibernate_asm_64.S +++ b/arch/x86/power/hibernate_asm_64.S @@ -68,6 +68,7 @@ ENTRY(restore_image) /* jump to relocated restore code */ movq relocated_restore_code(%rip), %rcx jmpq *%rcx +ENDPROC(restore_image) /* code below has been relocated to a safe page */ ENTRY(core_restore_code) @@ -98,6 +99,7 @@ ENTRY(core_restore_code) .Ldone: /* jump to the restore_registers address from the image header */ jmpq *%r8 +ENDPROC(core_restore_code) /* code below belongs to the image kernel */ .align PAGE_SIZE diff --git a/arch/x86/realmode/rm/reboot.S b/arch/x86/realmode/rm/reboot.S index d66c607bdc58..c8855d50f9c1 100644 --- a/arch/x86/realmode/rm/reboot.S +++ b/arch/x86/realmode/rm/reboot.S @@ -62,6 +62,7 @@ GLOBAL(machine_real_restart_paging_off) movl %ecx, %gs movl %ecx, %ss ljmpw $8, $1f +ENDPROC(machine_real_restart_asm) /* * This is 16-bit protected mode code to disable paging and the cache, diff --git a/arch/x86/realmode/rm/trampoline_64.S b/arch/x86/realmode/rm/trampoline_64.S index dac7b20d2f9d..fe21a26a09fe 100644 --- a/arch/x86/realmode/rm/trampoline_64.S +++ b/arch/x86/realmode/rm/trampoline_64.S @@ -79,6 +79,8 @@ ENTRY(trampoline_start) no_longmode: hlt jmp no_longmode +ENDPROC(trampoline_start) + #include "../kernel/verify_cpu.S" .section ".text32","ax" @@ -116,6 +118,7 @@ ENTRY(startup_32) * the new gdt/idt that has __KERNEL_CS with CS.L = 1. */ ljmpl $__KERNEL_CS, $pa_startup_64 +ENDPROC(startup_32) .section ".text64","ax" .code64 @@ -123,6 +126,7 @@ ENTRY(startup_32) ENTRY(startup_64) # Now jump into the kernel using virtual addresses jmpq *tr_start(%rip) +ENDPROC(startup_64) .section ".rodata","a" # Duplicate the global descriptor table diff --git a/arch/x86/realmode/rm/wakeup_asm.S b/arch/x86/realmode/rm/wakeup_asm.S index 9e7e14797a72..08203a187446 100644 --- a/arch/x86/realmode/rm/wakeup_asm.S +++ b/arch/x86/realmode/rm/wakeup_asm.S @@ -134,6 +134,7 @@ ENTRY(wakeup_start) #else jmp trampoline_start #endif +ENDPROC(wakeup_start) bogus_real_magic: 1: diff --git a/arch/x86/xen/xen-asm_64.S b/arch/x86/xen/xen-asm_64.S index c3df43141e70..d617bea76039 100644 --- a/arch/x86/xen/xen-asm_64.S +++ b/arch/x86/xen/xen-asm_64.S @@ -49,6 +49,7 @@ ENTRY(xen_iret) 1: jmp hypercall_iret ENDPATCH(xen_iret) RELOC(xen_iret, 1b+1) +ENDPROC(xen_iret) ENTRY(xen_sysret64) /* @@ -68,6 +69,7 @@ ENTRY(xen_sysret64) 1: jmp hypercall_iret ENDPATCH(xen_sysret64) RELOC(xen_sysret64, 1b+1) +ENDPROC(xen_sysret64) /* * Xen handles syscall callbacks much like ordinary exceptions, which diff --git a/arch/x86/xen/xen-head.S b/arch/x86/xen/xen-head.S index 39ea5484763a..0e793c1f0d45 100644 --- a/arch/x86/xen/xen-head.S +++ b/arch/x86/xen/xen-head.S @@ -32,7 +32,7 @@ ENTRY(startup_xen) mov $init_thread_union+THREAD_SIZE, %_ASM_SP jmp xen_start_kernel - +ENDPROC(startup_xen) __FINIT .pushsection .text diff --git a/arch/x86/xen/xen-pvh.S b/arch/x86/xen/xen-pvh.S index 5e246716d58f..512fda03c93f 100644 --- a/arch/x86/xen/xen-pvh.S +++ b/arch/x86/xen/xen-pvh.S @@ -133,7 +133,7 @@ ENTRY(pvh_start_xen) ljmp $__BOOT_CS, $_pa(startup_32) #endif -END(pvh_start_xen) +ENDPROC(pvh_start_xen) .section ".init.data","aw" .balign 8 -- 2.11.1 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel ^ permalink raw reply related [flat|nested] 18+ messages in thread
* Re: [PATCH 02/10] x86: assembly, use ENDPROC for functions 2017-02-17 10:47 ` [PATCH 02/10] x86: assembly, use ENDPROC for functions Jiri Slaby @ 2017-02-17 11:08 ` Juergen Gross 0 siblings, 0 replies; 18+ messages in thread From: Juergen Gross @ 2017-02-17 11:08 UTC (permalink / raw) To: Jiri Slaby, mingo Cc: hpa, linux-pm, x86, Rafael J. Wysocki, linux-kernel, Pavel Machek, jpoimboe, xen-devel, tglx, Boris Ostrovsky On 17/02/17 11:47, Jiri Slaby wrote: > Somewhere END was used to end a function, elsewhere, nothing was used. > So unify it and mark them all by ENDPROC. > > Signed-off-by: Jiri Slaby <jslaby@suse.cz> > Cc: Thomas Gleixner <tglx@linutronix.de> > Cc: Ingo Molnar <mingo@redhat.com> > Cc: "H. Peter Anvin" <hpa@zytor.com> > Cc: <x86@kernel.org> > Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net> > Cc: Pavel Machek <pavel@ucw.cz> > Cc: <linux-pm@vger.kernel.org> > Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com> > Cc: Juergen Gross <jgross@suse.com> > Cc: <xen-devel@lists.xenproject.org> > --- > arch/x86/entry/entry_64.S | 40 ++++++++++++++++++------------------ > arch/x86/entry/entry_64_compat.S | 4 ++-- > arch/x86/kernel/mcount_64.S | 10 +++++---- > arch/x86/power/hibernate_asm_64.S | 2 ++ > arch/x86/realmode/rm/reboot.S | 1 + > arch/x86/realmode/rm/trampoline_64.S | 4 ++++ > arch/x86/realmode/rm/wakeup_asm.S | 1 + > arch/x86/xen/xen-asm_64.S | 2 ++ > arch/x86/xen/xen-head.S | 2 +- > arch/x86/xen/xen-pvh.S | 2 +- > 10 files changed, 40 insertions(+), 28 deletions(-) Xen parts: Reviewed-by: Juergen Gross <jgross@suse.com> Juergen _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 18+ messages in thread
* [PATCH 08/10] x86: assembly, annotate aliases [not found] <20170217104757.28588-1-jslaby@suse.cz> 2017-02-17 10:47 ` [PATCH 02/10] x86: assembly, use ENDPROC for functions Jiri Slaby @ 2017-02-17 10:47 ` Jiri Slaby 2017-02-17 11:52 ` Juergen Gross 2017-02-17 11:06 ` [PATCH 01/10] x86: assembly, ENTRY for fn, GLOBAL for data Juergen Gross 2017-03-01 9:38 ` Ingo Molnar 3 siblings, 1 reply; 18+ messages in thread From: Jiri Slaby @ 2017-02-17 10:47 UTC (permalink / raw) To: mingo Cc: Juergen Gross, hpa, Herbert Xu, Boris Ostrovsky, x86, linux-kernel, linux-crypto, jpoimboe, xen-devel, tglx, Jiri Slaby, David S. Miller _key_expansion_128 is an alias to _key_expansion_256a, __memcpy to memcpy, xen_syscall32_target to xen_sysenter_target, and so on. Annotate them all using the new ENTRY_ALIAS and ENTRY_LOCAL_ALIAS. This will make the tools generating the debuginfo happy. Signed-off-by: Jiri Slaby <jslaby@suse.cz> Cc: Herbert Xu <herbert@gondor.apana.org.au> Cc: "David S. Miller" <davem@davemloft.net> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@redhat.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: <x86@kernel.org> Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com> Cc: Juergen Gross <jgross@suse.com> Cc: <linux-crypto@vger.kernel.org> Cc: <xen-devel@lists.xenproject.org> --- arch/x86/crypto/aesni-intel_asm.S | 5 ++--- arch/x86/lib/memcpy_64.S | 4 ++-- arch/x86/lib/memmove_64.S | 4 ++-- arch/x86/lib/memset_64.S | 4 ++-- arch/x86/xen/xen-asm_64.S | 4 ++-- 5 files changed, 10 insertions(+), 11 deletions(-) diff --git a/arch/x86/crypto/aesni-intel_asm.S b/arch/x86/crypto/aesni-intel_asm.S index 624e4303d0fb..6a0f25be1a56 100644 --- a/arch/x86/crypto/aesni-intel_asm.S +++ b/arch/x86/crypto/aesni-intel_asm.S @@ -1744,8 +1744,7 @@ ENDPROC(aesni_gcm_enc) #endif -.align 4 -_key_expansion_128: +ENTRY_LOCAL_ALIAS(_key_expansion_128) ENTRY_LOCAL(_key_expansion_256a) pshufd $0b11111111, %xmm1, %xmm1 shufps $0b00010000, %xmm0, %xmm4 @@ -1756,8 +1755,8 @@ ENTRY_LOCAL(_key_expansion_256a) movaps %xmm0, (TKEYP) add $0x10, TKEYP ret -ENDPROC(_key_expansion_128) ENDPROC(_key_expansion_256a) +END_ALIAS(_key_expansion_128) ENTRY_LOCAL(_key_expansion_192a) pshufd $0b01010101, %xmm1, %xmm1 diff --git a/arch/x86/lib/memcpy_64.S b/arch/x86/lib/memcpy_64.S index 779782f58324..c9ac54822e87 100644 --- a/arch/x86/lib/memcpy_64.S +++ b/arch/x86/lib/memcpy_64.S @@ -26,7 +26,7 @@ * Output: * rax original destination */ -ENTRY(__memcpy) +ENTRY_ALIAS(__memcpy) ENTRY(memcpy) ALTERNATIVE_2 "jmp memcpy_orig", "", X86_FEATURE_REP_GOOD, \ "jmp memcpy_erms", X86_FEATURE_ERMS @@ -40,7 +40,7 @@ ENTRY(memcpy) rep movsb ret ENDPROC(memcpy) -ENDPROC(__memcpy) +END_ALIAS(__memcpy) EXPORT_SYMBOL(memcpy) EXPORT_SYMBOL(__memcpy) diff --git a/arch/x86/lib/memmove_64.S b/arch/x86/lib/memmove_64.S index 15de86cd15b0..76f54ba3dd26 100644 --- a/arch/x86/lib/memmove_64.S +++ b/arch/x86/lib/memmove_64.S @@ -25,7 +25,7 @@ */ .weak memmove -ENTRY(memmove) +ENTRY_ALIAS(memmove) ENTRY(__memmove) /* Handle more 32 bytes in loop */ @@ -207,6 +207,6 @@ ENTRY(__memmove) 13: retq ENDPROC(__memmove) -ENDPROC(memmove) +END_ALIAS(memmove) EXPORT_SYMBOL(__memmove) EXPORT_SYMBOL(memmove) diff --git a/arch/x86/lib/memset_64.S b/arch/x86/lib/memset_64.S index 55b95db30a61..be6c4705ec51 100644 --- a/arch/x86/lib/memset_64.S +++ b/arch/x86/lib/memset_64.S @@ -18,7 +18,7 @@ * * rax original destination */ -ENTRY(memset) +ENTRY_ALIAS(memset) ENTRY(__memset) /* * Some CPUs support enhanced REP MOVSB/STOSB feature. It is recommended @@ -42,8 +42,8 @@ ENTRY(__memset) rep stosb movq %r9,%rax ret -ENDPROC(memset) ENDPROC(__memset) +END_ALIAS(memset) EXPORT_SYMBOL(memset) EXPORT_SYMBOL(__memset) diff --git a/arch/x86/xen/xen-asm_64.S b/arch/x86/xen/xen-asm_64.S index d617bea76039..4b0fe749f10c 100644 --- a/arch/x86/xen/xen-asm_64.S +++ b/arch/x86/xen/xen-asm_64.S @@ -117,13 +117,13 @@ ENDPROC(xen_sysenter_target) #else /* !CONFIG_IA32_EMULATION */ -ENTRY(xen_syscall32_target) +ENTRY_ALIAS(xen_syscall32_target) ENTRY(xen_sysenter_target) lea 16(%rsp), %rsp /* strip %rcx, %r11 */ mov $-ENOSYS, %rax pushq $0 jmp hypercall_iret -ENDPROC(xen_syscall32_target) ENDPROC(xen_sysenter_target) +END_ALIAS(xen_syscall32_target) #endif /* CONFIG_IA32_EMULATION */ -- 2.11.1 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel ^ permalink raw reply related [flat|nested] 18+ messages in thread
* Re: [PATCH 08/10] x86: assembly, annotate aliases 2017-02-17 10:47 ` [PATCH 08/10] x86: assembly, annotate aliases Jiri Slaby @ 2017-02-17 11:52 ` Juergen Gross 0 siblings, 0 replies; 18+ messages in thread From: Juergen Gross @ 2017-02-17 11:52 UTC (permalink / raw) To: Jiri Slaby, mingo Cc: hpa, Herbert Xu, Boris Ostrovsky, x86, linux-kernel, linux-crypto, jpoimboe, xen-devel, tglx, David S. Miller On 17/02/17 11:47, Jiri Slaby wrote: > _key_expansion_128 is an alias to _key_expansion_256a, __memcpy to > memcpy, xen_syscall32_target to xen_sysenter_target, and so on. Annotate > them all using the new ENTRY_ALIAS and ENTRY_LOCAL_ALIAS. This will make > the tools generating the debuginfo happy. > > Signed-off-by: Jiri Slaby <jslaby@suse.cz> > Cc: Herbert Xu <herbert@gondor.apana.org.au> > Cc: "David S. Miller" <davem@davemloft.net> > Cc: Thomas Gleixner <tglx@linutronix.de> > Cc: Ingo Molnar <mingo@redhat.com> > Cc: "H. Peter Anvin" <hpa@zytor.com> > Cc: <x86@kernel.org> > Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com> > Cc: Juergen Gross <jgross@suse.com> > Cc: <linux-crypto@vger.kernel.org> > Cc: <xen-devel@lists.xenproject.org> > --- > arch/x86/crypto/aesni-intel_asm.S | 5 ++--- > arch/x86/lib/memcpy_64.S | 4 ++-- > arch/x86/lib/memmove_64.S | 4 ++-- > arch/x86/lib/memset_64.S | 4 ++-- > arch/x86/xen/xen-asm_64.S | 4 ++-- > 5 files changed, 10 insertions(+), 11 deletions(-) Xen parts: Reviewed-by: Juergen Gross <jgross@suse.com> Juergen _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 01/10] x86: assembly, ENTRY for fn, GLOBAL for data [not found] <20170217104757.28588-1-jslaby@suse.cz> 2017-02-17 10:47 ` [PATCH 02/10] x86: assembly, use ENDPROC for functions Jiri Slaby 2017-02-17 10:47 ` [PATCH 08/10] x86: assembly, annotate aliases Jiri Slaby @ 2017-02-17 11:06 ` Juergen Gross 2017-03-01 9:38 ` Ingo Molnar 3 siblings, 0 replies; 18+ messages in thread From: Juergen Gross @ 2017-02-17 11:06 UTC (permalink / raw) To: Jiri Slaby, mingo Cc: Len Brown, hpa, linux-pm, x86, Rafael J. Wysocki, linux-kernel, Pavel Machek, jpoimboe, xen-devel, Boris Ostrovsky, tglx On 17/02/17 11:47, Jiri Slaby wrote: > This is a start of series to unify use of ENTRY, ENDPROC, GLOBAL, END, > and other macros across x86. When we have all this sorted out, this will > help to inject DWARF unwinding info by objtool later. > > So, let us use the macros this way: > * ENTRY -- start of a global function > * ENDPROC -- end of a local/global function > * GLOBAL -- start of a globally visible data symbol > * END -- end of local/global data symbol > > The goal is forcing ENTRY to emit .cfi_startproc and ENDPROC to emit > .cfi_endproc. > > This particular patch makes proper use of GLOBAL on data and ENTRY on a > function which was not the case on 4 locations. > > Signed-off-by: Jiri Slaby <jslaby@suse.cz> > Cc: Thomas Gleixner <tglx@linutronix.de> > Cc: Ingo Molnar <mingo@redhat.com> > Cc: "H. Peter Anvin" <hpa@zytor.com> > Cc: <x86@kernel.org> > Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com> > Cc: Juergen Gross <jgross@suse.com> > Cc: <xen-devel@lists.xenproject.org> > Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net> > Cc: Len Brown <len.brown@intel.com> > Cc: Pavel Machek <pavel@ucw.cz> > Cc: <linux-pm@vger.kernel.org> > --- > arch/x86/kernel/acpi/wakeup_64.S | 14 +++++++------- > arch/x86/kernel/head_64.S | 2 +- > arch/x86/kernel/mcount_64.S | 2 +- > arch/x86/xen/xen-head.S | 2 +- > 4 files changed, 10 insertions(+), 10 deletions(-) Xen parts: Reviewed-by: Juergen Gross <jgross@suse.com> Juergen _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 01/10] x86: assembly, ENTRY for fn, GLOBAL for data [not found] <20170217104757.28588-1-jslaby@suse.cz> ` (2 preceding siblings ...) 2017-02-17 11:06 ` [PATCH 01/10] x86: assembly, ENTRY for fn, GLOBAL for data Juergen Gross @ 2017-03-01 9:38 ` Ingo Molnar 2017-03-01 9:50 ` Jiri Slaby ` (2 more replies) 3 siblings, 3 replies; 18+ messages in thread From: Ingo Molnar @ 2017-03-01 9:38 UTC (permalink / raw) To: Jiri Slaby Cc: Juergen Gross, Len Brown, hpa, Andrew Morton, linux-pm, x86, Rafael J. Wysocki, linux-kernel, mingo, Pavel Machek, jpoimboe, xen-devel, tglx, Linus Torvalds, Boris Ostrovsky, Peter Zijlstra * Jiri Slaby <jslaby@suse.cz> wrote: > This is a start of series to unify use of ENTRY, ENDPROC, GLOBAL, END, > and other macros across x86. When we have all this sorted out, this will > help to inject DWARF unwinding info by objtool later. > > So, let us use the macros this way: > * ENTRY -- start of a global function > * ENDPROC -- end of a local/global function > * GLOBAL -- start of a globally visible data symbol > * END -- end of local/global data symbol So how about using macro names that actually show the purpose, instead of importing all the crappy, historic, essentially randomly chosen debug symbol macro names from the binutils and older kernels? Something sane, like: SYM__FUNCTION_START SYM__FUNCTION_END SYM__DATA_START SYM__DATA_END ... and extend that macro namespace with any other variants we might need. We can still keep the old macro names (for a short while) to ease the transition, but for heaven's sake, if we do "cleanups" before complicating the code let's make sure the result is actually readable! Agreed? Thanks, Ingo _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 01/10] x86: assembly, ENTRY for fn, GLOBAL for data 2017-03-01 9:38 ` Ingo Molnar @ 2017-03-01 9:50 ` Jiri Slaby 2017-03-01 10:09 ` Thomas Gleixner [not found] ` <alpine.DEB.2.20.1703011108220.4005@nanos> 2 siblings, 0 replies; 18+ messages in thread From: Jiri Slaby @ 2017-03-01 9:50 UTC (permalink / raw) To: Ingo Molnar Cc: Juergen Gross, Len Brown, hpa, Andrew Morton, linux-pm, x86, Rafael J. Wysocki, linux-kernel, mingo, Pavel Machek, jpoimboe, xen-devel, tglx, Linus Torvalds, Boris Ostrovsky, Peter Zijlstra On 03/01/2017, 10:38 AM, Ingo Molnar wrote: > Agreed? Sure. I wanted to keep it minimal to see if you agree with this direction at all. No problem to be more intrusive :). thanks, -- js suse labs _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 01/10] x86: assembly, ENTRY for fn, GLOBAL for data 2017-03-01 9:38 ` Ingo Molnar 2017-03-01 9:50 ` Jiri Slaby @ 2017-03-01 10:09 ` Thomas Gleixner [not found] ` <alpine.DEB.2.20.1703011108220.4005@nanos> 2 siblings, 0 replies; 18+ messages in thread From: Thomas Gleixner @ 2017-03-01 10:09 UTC (permalink / raw) To: Ingo Molnar Cc: Juergen Gross, Len Brown, hpa, Peter Zijlstra, linux-pm, Linus Torvalds, x86, Rafael J. Wysocki, linux-kernel, mingo, Pavel Machek, jpoimboe, xen-devel, Boris Ostrovsky, Jiri Slaby, Andrew Morton On Wed, 1 Mar 2017, Ingo Molnar wrote: > > * Jiri Slaby <jslaby@suse.cz> wrote: > > > This is a start of series to unify use of ENTRY, ENDPROC, GLOBAL, END, > > and other macros across x86. When we have all this sorted out, this will > > help to inject DWARF unwinding info by objtool later. > > > > So, let us use the macros this way: > > * ENTRY -- start of a global function > > * ENDPROC -- end of a local/global function > > * GLOBAL -- start of a globally visible data symbol > > * END -- end of local/global data symbol > > So how about using macro names that actually show the purpose, instead of > importing all the crappy, historic, essentially randomly chosen debug symbol macro > names from the binutils and older kernels? > > Something sane, like: > > SYM__FUNCTION_START Sane would be: SYM_FUNCTION_START The double underscore is just not giving any value. Thanks, tglx _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 18+ messages in thread
[parent not found: <alpine.DEB.2.20.1703011108220.4005@nanos>]
* Re: [PATCH 01/10] x86: assembly, ENTRY for fn, GLOBAL for data [not found] ` <alpine.DEB.2.20.1703011108220.4005@nanos> @ 2017-03-01 10:27 ` Ingo Molnar 2017-03-03 12:22 ` Jiri Slaby ` (2 more replies) 0 siblings, 3 replies; 18+ messages in thread From: Ingo Molnar @ 2017-03-01 10:27 UTC (permalink / raw) To: Thomas Gleixner Cc: Juergen Gross, Len Brown, hpa, Peter Zijlstra, linux-pm, Linus Torvalds, x86, Rafael J. Wysocki, linux-kernel, mingo, Pavel Machek, jpoimboe, xen-devel, Boris Ostrovsky, Jiri Slaby, Andrew Morton * Thomas Gleixner <tglx@linutronix.de> wrote: > On Wed, 1 Mar 2017, Ingo Molnar wrote: > > > > * Jiri Slaby <jslaby@suse.cz> wrote: > > > > > This is a start of series to unify use of ENTRY, ENDPROC, GLOBAL, END, > > > and other macros across x86. When we have all this sorted out, this will > > > help to inject DWARF unwinding info by objtool later. > > > > > > So, let us use the macros this way: > > > * ENTRY -- start of a global function > > > * ENDPROC -- end of a local/global function > > > * GLOBAL -- start of a globally visible data symbol > > > * END -- end of local/global data symbol > > > > So how about using macro names that actually show the purpose, instead of > > importing all the crappy, historic, essentially randomly chosen debug symbol macro > > names from the binutils and older kernels? > > > > Something sane, like: > > > > SYM__FUNCTION_START > > Sane would be: > > SYM_FUNCTION_START > > The double underscore is just not giving any value. So the double underscore (at least in my view) has two advantages: 1) it helps separate the prefix from the postfix. I.e. it's a 'symbols' namespace, and a 'function start', not the 'start' of a 'symbol function'. 2) It also helps easy greppability. Try this in latest -tip: git grep e820__ To see all the E820 API calls - with no false positives! 'git grep e820_' on the other hand is a lot less reliable... But no strong feelings either way, I just try to sneak in these small namespace structure tricks when nobody's looking! ;-) Thanks, Ingo _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 01/10] x86: assembly, ENTRY for fn, GLOBAL for data 2017-03-01 10:27 ` Ingo Molnar @ 2017-03-03 12:22 ` Jiri Slaby 2017-03-03 18:20 ` hpa 2017-03-03 18:24 ` hpa 2 siblings, 0 replies; 18+ messages in thread From: Jiri Slaby @ 2017-03-03 12:22 UTC (permalink / raw) To: Ingo Molnar, Thomas Gleixner Cc: Juergen Gross, Len Brown, hpa, Peter Zijlstra, linux-pm, x86, Rafael J. Wysocki, linux-kernel, mingo, Pavel Machek, jpoimboe, xen-devel, Boris Ostrovsky, Linus Torvalds, Andrew Morton On 03/01/2017, 11:27 AM, Ingo Molnar wrote: > But no strong feelings either way, I just try to sneak in these small namespace > structure tricks when nobody's looking! ;-) So I assume to introduce two underscores. thanks, -- js suse labs _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 01/10] x86: assembly, ENTRY for fn, GLOBAL for data 2017-03-01 10:27 ` Ingo Molnar 2017-03-03 12:22 ` Jiri Slaby @ 2017-03-03 18:20 ` hpa 2017-03-06 14:09 ` Jiri Slaby 2017-03-07 7:57 ` Ingo Molnar 2017-03-03 18:24 ` hpa 2 siblings, 2 replies; 18+ messages in thread From: hpa @ 2017-03-03 18:20 UTC (permalink / raw) To: Ingo Molnar, Thomas Gleixner Cc: Juergen Gross, Len Brown, Peter Zijlstra, linux-pm, Linus Torvalds, x86, Rafael J. Wysocki, linux-kernel, mingo, Pavel Machek, jpoimboe, xen-devel, Boris Ostrovsky, Jiri Slaby, Andrew Morton On March 1, 2017 2:27:54 AM PST, Ingo Molnar <mingo@kernel.org> wrote: > >* Thomas Gleixner <tglx@linutronix.de> wrote: > >> On Wed, 1 Mar 2017, Ingo Molnar wrote: >> > >> > * Jiri Slaby <jslaby@suse.cz> wrote: >> > >> > > This is a start of series to unify use of ENTRY, ENDPROC, GLOBAL, >END, >> > > and other macros across x86. When we have all this sorted out, >this will >> > > help to inject DWARF unwinding info by objtool later. >> > > >> > > So, let us use the macros this way: >> > > * ENTRY -- start of a global function >> > > * ENDPROC -- end of a local/global function >> > > * GLOBAL -- start of a globally visible data symbol >> > > * END -- end of local/global data symbol >> > >> > So how about using macro names that actually show the purpose, >instead of >> > importing all the crappy, historic, essentially randomly chosen >debug symbol macro >> > names from the binutils and older kernels? >> > >> > Something sane, like: >> > >> > SYM__FUNCTION_START >> >> Sane would be: >> >> SYM_FUNCTION_START >> >> The double underscore is just not giving any value. > >So the double underscore (at least in my view) has two advantages: > >1) it helps separate the prefix from the postfix. > >I.e. it's a 'symbols' namespace, and a 'function start', not the >'start' of a >'symbol function'. > >2) It also helps easy greppability. > >Try this in latest -tip: > > git grep e820__ > >To see all the E820 API calls - with no false positives! > >'git grep e820_' on the other hand is a lot less reliable... > >But no strong feelings either way, I just try to sneak in these small >namespace >structure tricks when nobody's looking! ;-) > >Thanks, > > Ingo This seems needlessly verbose to me and clutters the code. How about: PROC..ENDPROC, LOCALPROC..ENDPROC and DATA..ENDDATA. Clear, unambiguous and balanced. -- Sent from my Android device with K-9 Mail. Please excuse my brevity. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 01/10] x86: assembly, ENTRY for fn, GLOBAL for data 2017-03-03 18:20 ` hpa @ 2017-03-06 14:09 ` Jiri Slaby 2017-03-07 7:57 ` Ingo Molnar 1 sibling, 0 replies; 18+ messages in thread From: Jiri Slaby @ 2017-03-06 14:09 UTC (permalink / raw) To: hpa, Ingo Molnar, Thomas Gleixner Cc: Juergen Gross, Len Brown, Peter Zijlstra, linux-pm, x86, Rafael J. Wysocki, linux-kernel, mingo, Pavel Machek, jpoimboe, xen-devel, Boris Ostrovsky, Linus Torvalds, Andrew Morton On 03/03/2017, 07:20 PM, hpa@zytor.com wrote: > On March 1, 2017 2:27:54 AM PST, Ingo Molnar <mingo@kernel.org> wrote: >> >> * Thomas Gleixner <tglx@linutronix.de> wrote: >> >>> On Wed, 1 Mar 2017, Ingo Molnar wrote: >>>> >>>> * Jiri Slaby <jslaby@suse.cz> wrote: >>>> >>>>> This is a start of series to unify use of ENTRY, ENDPROC, GLOBAL, >> END, >>>>> and other macros across x86. When we have all this sorted out, >> this will >>>>> help to inject DWARF unwinding info by objtool later. >>>>> >>>>> So, let us use the macros this way: >>>>> * ENTRY -- start of a global function >>>>> * ENDPROC -- end of a local/global function >>>>> * GLOBAL -- start of a globally visible data symbol >>>>> * END -- end of local/global data symbol >>>> >>>> So how about using macro names that actually show the purpose, >> instead of >>>> importing all the crappy, historic, essentially randomly chosen >> debug symbol macro >>>> names from the binutils and older kernels? >>>> >>>> Something sane, like: >>>> >>>> SYM__FUNCTION_START >>> >>> Sane would be: >>> >>> SYM_FUNCTION_START >>> >>> The double underscore is just not giving any value. >> >> So the double underscore (at least in my view) has two advantages: >> >> 1) it helps separate the prefix from the postfix. >> >> I.e. it's a 'symbols' namespace, and a 'function start', not the >> 'start' of a >> 'symbol function'. >> >> 2) It also helps easy greppability. >> >> Try this in latest -tip: >> >> git grep e820__ >> >> To see all the E820 API calls - with no false positives! >> >> 'git grep e820_' on the other hand is a lot less reliable... >> >> But no strong feelings either way, I just try to sneak in these small >> namespace >> structure tricks when nobody's looking! ;-) >> >> Thanks, >> >> Ingo > > This seems needlessly verbose to me and clutters the code. > > How about: > > PROC..ENDPROC, LOCALPROC..ENDPROC and DATA..ENDDATA. Clear, unambiguous and balanced. I tried this, but: arch/x86/kernel/relocate_kernel_64.S:27:0: warning: "DATA" redefined #define DATA(offset) (KEXEC_CONTROL_CODE_MAX_SIZE+(offset)) I am not saying that I cannot fix it up. I just want to say, that these names might be too generic, especially "PROC" and "DATA". So should I really stick to these? thanks, -- js suse labs _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 01/10] x86: assembly, ENTRY for fn, GLOBAL for data 2017-03-03 18:20 ` hpa 2017-03-06 14:09 ` Jiri Slaby @ 2017-03-07 7:57 ` Ingo Molnar 1 sibling, 0 replies; 18+ messages in thread From: Ingo Molnar @ 2017-03-07 7:57 UTC (permalink / raw) To: hpa Cc: Juergen Gross, Len Brown, Andrew Morton, linux-pm, Linus Torvalds, x86, Rafael J. Wysocki, linux-kernel, mingo, Pavel Machek, jpoimboe, xen-devel, Thomas Gleixner, Jiri Slaby, Boris Ostrovsky, Peter Zijlstra * hpa@zytor.com <hpa@zytor.com> wrote: > On March 1, 2017 2:27:54 AM PST, Ingo Molnar <mingo@kernel.org> wrote: > > > >* Thomas Gleixner <tglx@linutronix.de> wrote: > > > >> On Wed, 1 Mar 2017, Ingo Molnar wrote: > >> > > >> > * Jiri Slaby <jslaby@suse.cz> wrote: > >> > > >> > > This is a start of series to unify use of ENTRY, ENDPROC, GLOBAL, > >END, > >> > > and other macros across x86. When we have all this sorted out, > >this will > >> > > help to inject DWARF unwinding info by objtool later. > >> > > > >> > > So, let us use the macros this way: > >> > > * ENTRY -- start of a global function > >> > > * ENDPROC -- end of a local/global function > >> > > * GLOBAL -- start of a globally visible data symbol > >> > > * END -- end of local/global data symbol > >> > > >> > So how about using macro names that actually show the purpose, > >instead of > >> > importing all the crappy, historic, essentially randomly chosen > >debug symbol macro > >> > names from the binutils and older kernels? > >> > > >> > Something sane, like: > >> > > >> > SYM__FUNCTION_START > >> > >> Sane would be: > >> > >> SYM_FUNCTION_START > >> > >> The double underscore is just not giving any value. > > > >So the double underscore (at least in my view) has two advantages: > > > >1) it helps separate the prefix from the postfix. > > > >I.e. it's a 'symbols' namespace, and a 'function start', not the > >'start' of a > >'symbol function'. > > > >2) It also helps easy greppability. > > > >Try this in latest -tip: > > > > git grep e820__ > > > >To see all the E820 API calls - with no false positives! > > > >'git grep e820_' on the other hand is a lot less reliable... > > > >But no strong feelings either way, I just try to sneak in these small > >namespace > >structure tricks when nobody's looking! ;-) > > > >Thanks, > > > > Ingo > > This seems needlessly verbose to me and clutters the code. > > How about: > > PROC..ENDPROC, LOCALPROC..ENDPROC and DATA..ENDDATA. Clear, unambiguous and balanced. I'm sorry, but that naming scheme is disgusing, it reminds me of BASIC nomenclature ... did we run out of underscores or what? Nor would clearly structured names clutter anything, this isn't going to be used deep inside nested code, it's going to be the single level syntactic term in addition to the symbol name itself: SYM__FUNCTION_START(some_kernel_asm_function) ... SYM__FUNCTION_END(some_kernel_asm_function) We could shorten it to 'FUNC' if length is really an issue: SYM__FUNC_START(some_kernel_asm_function) ... SYM__FUNC_END(some_kernel_asm_function) Also, 'PROC', presumably standing for 'procedure', is both ambiguous and a misnomer: - it's ambiguous with commonly used abbreviations of procfs and process - C functions are not actually 'procedures'. Procedures in PASCAL style languages denote functions that don't return any values. Most of the kernel asm functions actually do. I realize that even in C we sometimes talk about 'procedures' out of hysterical inertia, but if you check the C standards, most of them don't even use the term 'procedure'. 'function' on the other hand is totally unambiguous. Plus the lack of START/STOP (or BEGIN/END) makes it easy to commit the mistake of forgetting to add the end marker, and your naming scheme preserves that! So if we fix/extend these macros then _PLEASE_ we need to get this stupid, illogical, nonsensical, external tooling inherited naming craziness fixed first, not doubled down on... </rant> Thanks, Ingo _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 01/10] x86: assembly, ENTRY for fn, GLOBAL for data 2017-03-01 10:27 ` Ingo Molnar 2017-03-03 12:22 ` Jiri Slaby 2017-03-03 18:20 ` hpa @ 2017-03-03 18:24 ` hpa 2017-03-07 8:27 ` Ingo Molnar 2 siblings, 1 reply; 18+ messages in thread From: hpa @ 2017-03-03 18:24 UTC (permalink / raw) To: Ingo Molnar, Thomas Gleixner Cc: Juergen Gross, Len Brown, Peter Zijlstra, linux-pm, Linus Torvalds, x86, Rafael J. Wysocki, linux-kernel, mingo, Pavel Machek, jpoimboe, xen-devel, Boris Ostrovsky, Jiri Slaby, Andrew Morton On March 1, 2017 2:27:54 AM PST, Ingo Molnar <mingo@kernel.org> wrote: > >* Thomas Gleixner <tglx@linutronix.de> wrote: > >> On Wed, 1 Mar 2017, Ingo Molnar wrote: >> > >> > * Jiri Slaby <jslaby@suse.cz> wrote: >> > >> > > This is a start of series to unify use of ENTRY, ENDPROC, GLOBAL, >END, >> > > and other macros across x86. When we have all this sorted out, >this will >> > > help to inject DWARF unwinding info by objtool later. >> > > >> > > So, let us use the macros this way: >> > > * ENTRY -- start of a global function >> > > * ENDPROC -- end of a local/global function >> > > * GLOBAL -- start of a globally visible data symbol >> > > * END -- end of local/global data symbol >> > >> > So how about using macro names that actually show the purpose, >instead of >> > importing all the crappy, historic, essentially randomly chosen >debug symbol macro >> > names from the binutils and older kernels? >> > >> > Something sane, like: >> > >> > SYM__FUNCTION_START >> >> Sane would be: >> >> SYM_FUNCTION_START >> >> The double underscore is just not giving any value. > >So the double underscore (at least in my view) has two advantages: > >1) it helps separate the prefix from the postfix. > >I.e. it's a 'symbols' namespace, and a 'function start', not the >'start' of a >'symbol function'. > >2) It also helps easy greppability. > >Try this in latest -tip: > > git grep e820__ > >To see all the E820 API calls - with no false positives! > >'git grep e820_' on the other hand is a lot less reliable... > >But no strong feelings either way, I just try to sneak in these small >namespace >structure tricks when nobody's looking! ;-) > >Thanks, > > Ingo IMO these little "namespace tricks" especially for small common macros like we are taking about here make the code very frustrating to read, and even more to write. Noone would design a programming language that way, and things like PROC are really just substitutes for proper language features (and could even be as assembly rather than cpp macros.) When I say frustrating I mean, at least for me, full-Ballmer launch-chair-at-monitor level frustrating. -- Sent from my Android device with K-9 Mail. Please excuse my brevity. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 01/10] x86: assembly, ENTRY for fn, GLOBAL for data 2017-03-03 18:24 ` hpa @ 2017-03-07 8:27 ` Ingo Molnar 2017-03-07 17:24 ` [RFC] linkage: new macros for functions and data Jiri Slaby 0 siblings, 1 reply; 18+ messages in thread From: Ingo Molnar @ 2017-03-07 8:27 UTC (permalink / raw) To: hpa Cc: Juergen Gross, Len Brown, Andrew Morton, linux-pm, Linus Torvalds, x86, Rafael J. Wysocki, linux-kernel, mingo, Pavel Machek, jpoimboe, xen-devel, Thomas Gleixner, Jiri Slaby, Boris Ostrovsky, Peter Zijlstra * hpa@zytor.com <hpa@zytor.com> wrote: > On March 1, 2017 2:27:54 AM PST, Ingo Molnar <mingo@kernel.org> wrote: > >> > So how about using macro names that actually show the purpose, instead of > >> > importing all the crappy, historic, essentially randomly chosen debug > >> > symbol macro names from the binutils and older kernels? > >> > > >> > Something sane, like: > >> > > >> > SYM__FUNCTION_START > >> > >> Sane would be: > >> > >> SYM_FUNCTION_START > >> > >> The double underscore is just not giving any value. > > > > So the double underscore (at least in my view) has two advantages: > > > > 1) it helps separate the prefix from the postfix. > > > > I.e. it's a 'symbols' namespace, and a 'function start', not the 'start' of a > > 'symbol function'. > > > > 2) It also helps easy greppability. > > > > Try this in latest -tip: > > > > git grep e820__ > > > > To see all the E820 API calls - with no false positives! > > > > 'git grep e820_' on the other hand is a lot less reliable... > > IMO these little "namespace tricks" especially for small common macros like we > are taking about here make the code very frustrating to read, and even more to > write. Noone would design a programming language that way, and things like PROC > are really just substitutes for proper language features (and could even be as > assembly rather than cpp macros.) This is a totally different thing from language keywords which needs to be short and concise for obvious reasons. Keywords of languages get nested and are used all the time, and everyone needs to know them and they need to stay out of the way. The symbol start/end macros we are talking about here are _MUCH_ less common, and they are only ever used in a single nesting level: SYM__FUNC_START(some_kernel_asm_function) ... SYM__FUNC_END(some_kernel_asm_function) Most kernel developers writing new assembly code rarely know these constructs by heart, they just look them up and carbon copy existing practices. And guess what, the 'looking them up' gets harder if the macro naming scheme is an idosyncratic leftover from long ago. Kernel developers _reading_ assembly code will know the exact purpose of the macros even less, especially if they are named in an ambiguous, illogical fashion. Furthermore, your suggestion of: > PROC..ENDPROC, LOCALPROC..ENDPROC and DATA..ENDDATA. Clear, unambiguous and > balanced. Are neither clear, not unambiguous nor balanced! I mean, they are the _exact_ opposite: - 'PROC' is actually ambiguous in the kernel source code context, as it clashes with common abbreviations of 'procfs' and 'process'. It's also an unnecessary abbreviation of a word ('procedure') that is not actually used a _single time_ in the C ISO/IEC 9899:TC2 standard - in all half thousand+ pages of it. (!) Why the hell does this have to be used in the kernel? - It's visually and semantically imbalanced, because some terms have an 'END' prefix, but there's no matching 'START' or 'BEGIN' prefix for their counterparts. This makes it easy to commit various symbol definition termination errors, like: PROC(some_kernel_asm_function) ... Here it's not obvious that it needs an ENDPROC. While if it's written as: SYM__FUNC_START(some_kernel_asm_function) ... ... it's pretty obvious at first sight that an '_END' is missing! - What you suggest also has senselessly missing underscores, which makes it _more_ cluttered and less clear. We clearly don't have addtowaitqueue() and removefromwaitqueue() function names in the kernel, right? Why should we have 'ENDPROC' and 'ENDDATA' macro names? - Hierarchical naming schemes generally tend to put the more generic category name first, not last. So it's: mutex_init() mutex_lock() mutex_unlock() mutex_trylock() It's _NOT_ the other way around: init_mutex() lock_mutex() unlock_mutex() trylock_mutex() The prefix naming scheme is easier to read both visually/typographically (because it aligns vertically in a natural fashion so it's easier to pattern match), and also semantically: because when reading it it's easy to skip the line once your brain reads the generic category of 'mutex'. But with 'ENDPROC' my brain both has to needlessly perform the following steps: - disambiguate the 'END' and the 'PROC' - fill in the missing underscore - and finally when arriving at the generic term 'PROC', discard it as uninteresting - Short names have good use in programming languages, because everyone who uses that language knows what they are and they become a visual substitute for the language element. But assembly macros are _NOT_ a new language in this sense, they are actually more similar to library function names: where brevity is actually counterintuitive and harmful, because they are ambiguous and pollute the generic namespace. If you look at C library API function name best practices you'll see that the best ones are all hierarchically named and categorized, with the more generic category put first, they are unambiguously balanced even if that makes the names longer, they are clear and use underscores. For all these reasons the naming scheme you suggest is one of the worst we could come up with! I mean, if I had to _intentionally_ engineer something as harmful as possible to readability and maintainability this would be pretty close to it... I'm upset, because even a single minute of reflection should have told you all this. I mean, IMHO it's not even a close argument: your suggested naming scheme is bleeding from half a dozen of mortal wounds... I can be convinced to drop the double underscores (I seem to be in the minority regard them), and I can be convinced that 'FUNC' is shorter and still easy to understand instead of 'FUNCTION', but other than that please stop the naming madness! Thanks, Ingo _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 18+ messages in thread
* [RFC] linkage: new macros for functions and data 2017-03-07 8:27 ` Ingo Molnar @ 2017-03-07 17:24 ` Jiri Slaby 2017-03-16 8:02 ` Ingo Molnar 0 siblings, 1 reply; 18+ messages in thread From: Jiri Slaby @ 2017-03-07 17:24 UTC (permalink / raw) To: Ingo Molnar Cc: Juergen Gross, Len Brown, x86, Peter Zijlstra, linux-pm, Linus Torvalds, hpa, Rafael J. Wysocki, linux-kernel, mingo, Thomas Gleixner, Pavel Machek, jpoimboe, xen-devel, Boris Ostrovsky, Jiri Slaby, Andrew Morton SYM_LOCAL_ALIAS_START -- use where there are two local names for one code SYM_ALIAS_START -- use where there are two global names for one code SYM_LOCAL_FUNC_START -- use for local functions SYM_FUNCTION_START -- use for global functions SYM_WEAK_FUNC_START -- use for weak functions SYM_ALIAS_END -- the end of LOCALALIASed or ALIASed code SYM_FUNCTION_END -- the end of SYM_LOCAL_FUNC_START, SYM_FUNCTION_START, SYM_WEAK_FUNC_START, ... SYM_DATA_START -- global data symbol SYM_DATA_END -- the end of SYM_DATA_START symbol Signed-off-by: Jiri Slaby <jslaby@suse.cz> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com> Cc: hpa@zytor.com Cc: Ingo Molnar <mingo@kernel.org> Cc: jpoimboe@redhat.com Cc: Juergen Gross <jgross@suse.com> Cc: Len Brown <len.brown@intel.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: linux-kernel@vger.kernel.org Cc: linux-pm@vger.kernel.org Cc: mingo@redhat.com Cc: Pavel Machek <pavel@ucw.cz> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: xen-devel@lists.xenproject.org Cc: x86@kernel.org --- So this is what I have ATM. include/linux/linkage.h | 87 ++++++++++++++++++++++++++++++++++++++++--------- 1 file changed, 72 insertions(+), 15 deletions(-) diff --git a/include/linux/linkage.h b/include/linux/linkage.h index a6a42dd02466..79f634a57466 100644 --- a/include/linux/linkage.h +++ b/include/linux/linkage.h @@ -78,33 +78,90 @@ #define ALIGN __ALIGN #define ALIGN_STR __ALIGN_STR -#ifndef ENTRY -#define ENTRY(name) \ - .globl name ASM_NL \ +#ifndef ENTRY /* deprecated, use SYM_FUNCTION_START */ +#define ENTRY(name) SYM_FUNCTION_START(name) +#endif +#endif /* LINKER_SCRIPT */ + +/* === code annotations === */ + +/* SYM_LOCAL_ALIAS_START -- use where there are two local names for one code */ +#ifndef SYM_LOCAL_ALIAS_START +#define SYM_LOCAL_ALIAS_START(name) \ ALIGN ASM_NL \ name: #endif -#endif /* LINKER_SCRIPT */ -#ifndef WEAK -#define WEAK(name) \ +/* SYM_ALIAS_START -- use where there are two global names for one code */ +#ifndef SYM_ALIAS_START +#define SYM_ALIAS_START(name) \ + .globl name ASM_NL \ + SYM_LOCAL_ALIAS_START(name) +#endif + +/* + * so far the same as SYM_LOCAL_ALIAS_START, but we will need to distinguish + * them later + */ +/* SYM_LOCAL_FUNC_START -- use for local functions */ +#ifndef SYM_LOCAL_FUNC_START +#define SYM_LOCAL_FUNC_START(name) \ + SYM_LOCAL_ALIAS_START(name) +#endif + +/* SYM_FUNCTION_START -- use for global functions */ +#ifndef SYM_FUNCTION_START +#define SYM_FUNCTION_START(name) \ + .globl name ASM_NL \ + SYM_LOCAL_FUNC_START(name) +#endif + +/* SYM_WEAK_FUNC_START -- use for weak functions */ +#ifndef SYM_WEAK_FUNC_START +#define SYM_WEAK_FUNC_START(name) \ .weak name ASM_NL \ name: #endif -#ifndef END -#define END(name) \ - .size name, .-name +/* SYM_ALIAS_END -- the end of LOCALALIASed or ALIASed code */ +#ifndef SYM_ALIAS_END +#define SYM_ALIAS_END(name) \ + .type name, @function ASM_NL \ + SYM_DATA_END(name) #endif /* If symbol 'name' is treated as a subroutine (gets called, and returns) - * then please use ENDPROC to mark 'name' as STT_FUNC for the benefit of - * static analysis tools such as stack depth analyzer. + * then please use SYM_FUNCTION_END to mark 'name' as STT_FUNC for the benefit + * of static analysis tools such as stack depth analyzer. */ -#ifndef ENDPROC -#define ENDPROC(name) \ - .type name, @function ASM_NL \ - END(name) +/* + * SYM_FUNCTION_END -- the end of SYM_LOCAL_FUNC_START, SYM_FUNCTION_START, + * SYM_WEAK_FUNC_START, ... + */ +#ifndef SYM_FUNCTION_END +#define SYM_FUNCTION_END(name) \ + SYM_ALIAS_END(name) /* the same as for SYM_LOCAL_FUNC_START */ +#endif + +#ifndef WEAK /* deprecated, use SYM_WEAK_FUNC_START */ +#define WEAK(name) SYM_WEAK_FUNC_START(name) +#endif + +/* === data annotations === */ + +/* SYM_DATA_START -- global data symbol */ +#ifndef SYM_DATA_START +#define SYM_DATA_START(name) SYM_FUNCTION_START(name) +#endif + +/* SYM_DATA_END -- the end of SYM_DATA_START symbol */ +#ifndef SYM_DATA_END +#define SYM_DATA_END(name) \ + .size name, .-name +#endif + +#ifndef END /* deprecated, use SYM_DATA_END */ +#define END(name) SYM_DATA_END(name) #endif #endif -- 2.12.0 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel ^ permalink raw reply related [flat|nested] 18+ messages in thread
* Re: [RFC] linkage: new macros for functions and data 2017-03-07 17:24 ` [RFC] linkage: new macros for functions and data Jiri Slaby @ 2017-03-16 8:02 ` Ingo Molnar 2017-03-16 8:13 ` Jiri Slaby 0 siblings, 1 reply; 18+ messages in thread From: Ingo Molnar @ 2017-03-16 8:02 UTC (permalink / raw) To: Jiri Slaby Cc: Juergen Gross, Len Brown, x86, Peter Zijlstra, linux-pm, hpa, Rafael J. Wysocki, linux-kernel, mingo, Thomas Gleixner, Pavel Machek, jpoimboe, xen-devel, Boris Ostrovsky, Linus Torvalds, Andrew Morton * Jiri Slaby <jslaby@suse.cz> wrote: > SYM_LOCAL_ALIAS_START -- use where there are two local names for one code > SYM_ALIAS_START -- use where there are two global names for one code > SYM_LOCAL_FUNC_START -- use for local functions > SYM_FUNCTION_START -- use for global functions > SYM_WEAK_FUNC_START -- use for weak functions > SYM_ALIAS_END -- the end of LOCALALIASed or ALIASed code > SYM_FUNCTION_END -- the end of SYM_LOCAL_FUNC_START, SYM_FUNCTION_START, SYM_WEAK_FUNC_START, ... > SYM_DATA_START -- global data symbol > SYM_DATA_END -- the end of SYM_DATA_START symbol This looks mostly good to me, with minor details: - The mixed 'FUNC' and 'FUNCTION' naming looks a bit confusing - I'd pick one and use that consistently. - I'd also make the START/END constructs look more symmetric, i.e. make the attribute a postfix, not a prefix. - In fact I'd make the 'alias' notion an attribute as well - what matters mostly is that it's a function symbol, and that fact is lost from the SYM_ALIAS naming. I.e. something like this: SYM_FUNCTION_START SYM_FUNCTION_START_WEAK SYM_FUNCTION_START_LOCAL SYM_FUNCTION_START_ALIAS SYM_FUNCTION_START_LOCAL_ALIAS ... SYM_FUNCTION_END SYM_DATA_START SYM_DATA_END Note how simple and structured looking the nomenclature is when grouped in such a way, how easy it is to verify at a glance, and how easy it is to extend with new postfixes. ( In theory we could also make the attributes a real macro argument in the future, should the number of attributes increase significantly. ) Does this look good to everyone? Thanks, Ingo _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [RFC] linkage: new macros for functions and data 2017-03-16 8:02 ` Ingo Molnar @ 2017-03-16 8:13 ` Jiri Slaby 0 siblings, 0 replies; 18+ messages in thread From: Jiri Slaby @ 2017-03-16 8:13 UTC (permalink / raw) To: Ingo Molnar Cc: Juergen Gross, Len Brown, x86, Peter Zijlstra, linux-pm, hpa, Rafael J. Wysocki, linux-kernel, mingo, Thomas Gleixner, Pavel Machek, jpoimboe, xen-devel, Boris Ostrovsky, Linus Torvalds, Andrew Morton On 03/16/2017, 09:02 AM, Ingo Molnar wrote: > > * Jiri Slaby <jslaby@suse.cz> wrote: > >> SYM_LOCAL_ALIAS_START -- use where there are two local names for one code >> SYM_ALIAS_START -- use where there are two global names for one code >> SYM_LOCAL_FUNC_START -- use for local functions >> SYM_FUNCTION_START -- use for global functions >> SYM_WEAK_FUNC_START -- use for weak functions >> SYM_ALIAS_END -- the end of LOCALALIASed or ALIASed code >> SYM_FUNCTION_END -- the end of SYM_LOCAL_FUNC_START, SYM_FUNCTION_START, SYM_WEAK_FUNC_START, ... >> SYM_DATA_START -- global data symbol >> SYM_DATA_END -- the end of SYM_DATA_START symbol > > This looks mostly good to me, with minor details: > > - The mixed 'FUNC' and 'FUNCTION' naming looks a bit confusing - I'd pick one and > use that consistently. Of course, I did it later after sending the RFC. I stuck to FUNC. ... > Does this look good to everyone? Fine by me. I will send patches for that, so that you can comment on that on real uses. thanks, -- js suse labs _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2017-03-16 8:13 UTC | newest]
Thread overview: 18+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20170217104757.28588-1-jslaby@suse.cz>
2017-02-17 10:47 ` [PATCH 02/10] x86: assembly, use ENDPROC for functions Jiri Slaby
2017-02-17 11:08 ` Juergen Gross
2017-02-17 10:47 ` [PATCH 08/10] x86: assembly, annotate aliases Jiri Slaby
2017-02-17 11:52 ` Juergen Gross
2017-02-17 11:06 ` [PATCH 01/10] x86: assembly, ENTRY for fn, GLOBAL for data Juergen Gross
2017-03-01 9:38 ` Ingo Molnar
2017-03-01 9:50 ` Jiri Slaby
2017-03-01 10:09 ` Thomas Gleixner
[not found] ` <alpine.DEB.2.20.1703011108220.4005@nanos>
2017-03-01 10:27 ` Ingo Molnar
2017-03-03 12:22 ` Jiri Slaby
2017-03-03 18:20 ` hpa
2017-03-06 14:09 ` Jiri Slaby
2017-03-07 7:57 ` Ingo Molnar
2017-03-03 18:24 ` hpa
2017-03-07 8:27 ` Ingo Molnar
2017-03-07 17:24 ` [RFC] linkage: new macros for functions and data Jiri Slaby
2017-03-16 8:02 ` Ingo Molnar
2017-03-16 8:13 ` Jiri Slaby
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).