linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@kernel.org>
To: Jan Beulich <JBeulich@suse.com>
Cc: mingo@elte.hu, tglx@linutronix.de, hpa@zytor.com,
	Andy Lutomirski <luto@amacapital.net>,
	Denys Vlasenko <dvlasenk@redhat.com>,
	linux-kernel@vger.kernel.org,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Brian Gerst <brgerst@gmail.com>
Subject: Re: [PATCH] x86-64: fix unwind info for incomplete frames
Date: Thu, 28 May 2015 11:01:34 +0200	[thread overview]
Message-ID: <20150528090133.GA469@gmail.com> (raw)
In-Reply-To: <5566EBE7020000780007E659@mail.emea.novell.com>


* Jan Beulich <JBeulich@suse.com> wrote:

> Commit 76f5df43ca ('x86/asm/entry/64: Always allocate a complete
> "struct pt_regs" on the kernel stack') deleted PARTIAL_FRAME without
> considering that while a full frame is now being allocated, not all
> registers get always saved into it. Instead of restoring that macro,
> simply make DEFAULT_FRAME capable of expressing both.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> Cc: Denys Vlasenko <dvlasenk@redhat.com>
> Cc: Andy Lutomirski <luto@amacapital.net>
> ---
>  arch/x86/kernel/entry_64.S |   18 ++++++++++--------
>  1 file changed, 10 insertions(+), 8 deletions(-)
> 
> --- 4.1-rc5/arch/x86/kernel/entry_64.S
> +++ 4.1-rc5-x86_64-unwind-info/arch/x86/kernel/entry_64.S
> @@ -148,7 +148,7 @@ ENDPROC(native_usergs_sysret64)
>  /*
>   * frame that enables passing a complete pt_regs to a C function.
>   */
> -	.macro DEFAULT_FRAME start=1 offset=0
> +	.macro DEFAULT_FRAME start=1 offset=0 extra=1
>  	XCPT_FRAME \start, ORIG_RAX+\offset
>  	CFI_REL_OFFSET rdi, RDI+\offset
>  	CFI_REL_OFFSET rsi, RSI+\offset
> @@ -159,12 +159,14 @@ ENDPROC(native_usergs_sysret64)
>  	CFI_REL_OFFSET r9, R9+\offset
>  	CFI_REL_OFFSET r10, R10+\offset
>  	CFI_REL_OFFSET r11, R11+\offset
> +	.if \extra
>  	CFI_REL_OFFSET rbx, RBX+\offset
>  	CFI_REL_OFFSET rbp, RBP+\offset
>  	CFI_REL_OFFSET r12, R12+\offset
>  	CFI_REL_OFFSET r13, R13+\offset
>  	CFI_REL_OFFSET r14, R14+\offset
>  	CFI_REL_OFFSET r15, R15+\offset
> +	.endif
>  	.endm

I have a couple of code cleanliness complaints:

 - So 'extra' isn't very expressive, I'd name it 'full' to signal a full frame, 
   and full=0 denotes

 - So I had to go into the source and double check various nested macros to see 
   that DEFAULT_FRAME is only defining debug information, it's not emitting any 
   actual code. This should have been glaringly obvious from the macro name!

 - So I hate these 'default values' vararg-ish assembly macros:

arch/x86/kernel/entry_64.S:     DEFAULT_FRAME 0, 8              /* offset 8: return address */
arch/x86/kernel/entry_64.S:     DEFAULT_FRAME 0, 8
arch/x86/kernel/entry_64.S:     DEFAULT_FRAME 0, 8
arch/x86/kernel/entry_64.S:     DEFAULT_FRAME 0, 8
arch/x86/kernel/entry_64.S:     DEFAULT_FRAME 0, 8
arch/x86/kernel/entry_64.S:     DEFAULT_FRAME 0, 8
arch/x86/kernel/entry_64.S:     DEFAULT_FRAME 0, 8
arch/x86/kernel/entry_64.S:     DEFAULT_FRAME
arch/x86/kernel/entry_64.S:     DEFAULT_FRAME 0
arch/x86/kernel/entry_64.S:     DEFAULT_FRAME 0
arch/x86/kernel/entry_64.S:     DEFAULT_FRAME
arch/x86/kernel/entry_64.S:     DEFAULT_FRAME
arch/x86/kernel/entry_64.S:     DEFAULT_FRAME
arch/x86/kernel/entry_64.S:     DEFAULT_FRAME 0

    because unlike C functions they make the actual arguments a guessing game: 
    you always have to double check the macro definition itself - while the
    'savings' in terms of less code written are miniscule. So it actually obscures 
    macros.

    So these should be flattened, with clear, fixed length parameter signatures, 
    to make them as similar to regular C code as syntactically possible.

Thanks,

	Ingo

  reply	other threads:[~2015-05-28  9:01 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-28  8:20 [PATCH] x86-64: fix unwind info for incomplete frames Jan Beulich
2015-05-28  9:01 ` Ingo Molnar [this message]
2015-05-28  9:45   ` Jan Beulich
2015-05-28 11:20     ` [PATCH] x86/debug: Remove perpetually broken, unmaintainable dwarf annotations Ingo Molnar
2015-05-28 11:39       ` [PATCH v2] " Ingo Molnar
2015-05-28 11:51       ` [PATCH] " Jan Beulich
2015-05-28 13:17         ` Ingo Molnar
2015-05-29 17:47           ` Andy Lutomirski
2015-05-29 20:27             ` Josh Poimboeuf
2015-05-29 21:39               ` Frank Ch. Eigler
2015-06-01 19:45             ` Josh Poimboeuf
2015-06-01 19:53               ` Andy Lutomirski
2015-06-01 20:19                 ` Josh Poimboeuf
2015-06-02  5:57                 ` Ingo Molnar
2015-06-02 14:46                   ` Josh Poimboeuf
2015-06-02 17:00                     ` Andy Lutomirski
2015-06-05 17:11             ` Andi Kleen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150528090133.GA469@gmail.com \
    --to=mingo@kernel.org \
    --cc=JBeulich@suse.com \
    --cc=brgerst@gmail.com \
    --cc=dvlasenk@redhat.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@amacapital.net \
    --cc=mingo@elte.hu \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).