From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1434407AbdDZBm2 (ORCPT ); Tue, 25 Apr 2017 21:42:28 -0400 Received: from mx1.redhat.com ([209.132.183.28]:49944 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1434390AbdDZBmU (ORCPT ); Tue, 25 Apr 2017 21:42:20 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 6982D80481 Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=jpoimboe@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 6982D80481 Date: Tue, 25 Apr 2017 20:42:17 -0500 From: Josh Poimboeuf To: Jiri Slaby Cc: mingo@redhat.com, tglx@linutronix.de, hpa@zytor.com, x86@kernel.org, linux-kernel@vger.kernel.org, Boris Ostrovsky , Juergen Gross , xen-devel@lists.xenproject.org Subject: Re: [PATCH v3 04/29] x86: assembly, use ENDPROC for functions Message-ID: <20170426014217.hshjlweqsimaumuy@treble> References: <20170421141305.25180-1-jslaby@suse.cz> <20170421141305.25180-4-jslaby@suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20170421141305.25180-4-jslaby@suse.cz> User-Agent: Mutt/1.6.0.1 (2016-04-01) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Wed, 26 Apr 2017 01:42:19 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Apr 21, 2017 at 04:12:40PM +0200, Jiri Slaby wrote: > Somewhere END was used to end a function. It is not intended to be used > for functions, because it does not mark the actual symbols as functions. > Use ENDPROC in such cases which does the right job. > > Signed-off-by: Jiri Slaby > Cc: Thomas Gleixner > Cc: Ingo Molnar > Cc: "H. Peter Anvin" > Cc: > Cc: Boris Ostrovsky > Cc: Juergen Gross > Reviewed-by: Juergen Gross [xen parts] > Cc: > --- > arch/x86/entry/entry_32.S | 58 ++++++++++++++++++++-------------------- > arch/x86/entry/entry_64.S | 40 +++++++++++++-------------- > arch/x86/entry/entry_64_compat.S | 4 +-- > arch/x86/kernel/ftrace_32.S | 8 +++--- > arch/x86/kernel/ftrace_64.S | 10 +++---- > arch/x86/xen/xen-pvh.S | 2 +- > 6 files changed, 61 insertions(+), 61 deletions(-) > > diff --git a/arch/x86/entry/entry_32.S b/arch/x86/entry/entry_32.S > index 50bc26949e9e..a546b84aec01 100644 > --- a/arch/x86/entry/entry_32.S > +++ b/arch/x86/entry/entry_32.S > @@ -249,7 +249,7 @@ ENTRY(__switch_to_asm) > popl %ebp > > jmp __switch_to > -END(__switch_to_asm) > +ENDPROC(__switch_to_asm) > > /* > * A newly forked process directly context switches into this address. > @@ -289,7 +289,7 @@ ENTRY(ret_from_fork) > */ > movl $0, PT_EAX(%esp) > jmp 2b > -END(ret_from_fork) > +ENDPROC(ret_from_fork) > > /* > * Return to user mode is not as complex as all this looks, > @@ -323,7 +323,7 @@ ENTRY(resume_userspace) > movl %esp, %eax > call prepare_exit_to_usermode > jmp restore_all > -END(ret_from_exception) > +ENDPROC(ret_from_exception) What exactly is the motivation of this patch? It would be good to describe that in the commit message. Is the point to allow objtool to generate CFI for it? If so, I don't really see how that would work. Today, objtool considers ENDPROC to annotate a *callable* function which conforms to the C calling ABI and can be called by another function. The stack is in a known state at function entry, and so the CFI (or frame pointer info) can be reliably determined. But entry code is different. In most cases, the global symbols aren't actually called, and they don't follow any conventions. The code is spaghetti-esque, with HW handlers and jumps everywhere. The state of the stack at symbol entry varies per "function". That's why objtool ignores these files. For special cases (like entry code), I was thinking we'd need manual CFI annotations, like we had before. Or maybe there's another way, like some new macros which tell objtool about the HW entry points and the state of the registers there. But I'm having trouble seeing how marking these code snippets with ENTRY/ENDPROC would help objtool make any sense of the code and where things are on the stack. -- Josh