All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jiri Slaby <jslaby@suse.com>
To: Will Deacon <will@kernel.org>, Mark Brown <broonie@kernel.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 2/3] arm64: lib: Use modern annotations for assembly functions
Date: Fri, 10 Jan 2020 17:56:22 +0100	[thread overview]
Message-ID: <c241898d-3a0f-4356-0f2c-7d18ee35f45c@suse.com> (raw)
In-Reply-To: <20200108122957.GA16658@willie-the-truck>

On 08. 01. 20, 13:29, Will Deacon wrote:
> On Tue, Jan 07, 2020 at 05:47:41PM +0000, Mark Brown wrote:
>> On Tue, Jan 07, 2020 at 02:44:46PM +0000, Will Deacon wrote:
>>> Jiri -- is it ok to omit the stack frame for leaf functions annotated with
>>> SYM_FUNC_START? I'm guessing it should be, since the link register isn't
>>> going to be clobbered. Could we update the documentation to reflect that?
>>
>> Yeah, the documentation isn't great on that.  I was going on the basis
>> of both trying to minimize changes to the generated output as part of
>> the bulk change and looking at it from the point of view of the caller -
>> if as in this case the caller thinks it's a regular C function it seems
>> sensible to annotate it as such.
> 
> Maybe a small tweak to the documentation as per below, indicating that the
> stack stuff is just an x86-specific example?
> 
> Jiri?

Yes, the text in the documentation was too x86-specific. Could you send
the below as a proper patch? Thanks.

> diff --git a/Documentation/asm-annotations.rst b/Documentation/asm-annotations.rst
> index f55c2bb74d00..32ea57483378 100644
> --- a/Documentation/asm-annotations.rst
> +++ b/Documentation/asm-annotations.rst
> @@ -73,10 +73,11 @@ The new macros are prefixed with the ``SYM_`` prefix and can be divided into
>  three main groups:
>  
>  1. ``SYM_FUNC_*`` -- to annotate C-like functions. This means functions with
> -   standard C calling conventions, i.e. the stack contains a return address at
> -   the predefined place and a return from the function can happen in a
> -   standard way. When frame pointers are enabled, save/restore of frame
> -   pointer shall happen at the start/end of a function, respectively, too.
> +   standard C calling conventions. For example, on x86, this means that the
> +   stack contains a return address at the predefined place and a return from
> +   the function can happen in a standard way. When frame pointers are enabled,
> +   save/restore of frame pointer shall happen at the start/end of a function,
> +   respectively, too.
>  
>     Checking tools like ``objtool`` should ensure such marked functions conform
>     to these rules. The tools can also easily annotate these functions with

thanks,
-- 
js
suse labs

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2020-01-10 16:56 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-06 19:58 [PATCH 0/3] arm64: Conversions to modern assembly annotations Mark Brown
2020-01-06 19:58 ` [PATCH 1/3] arm64: asm: Add new-style position independent function annotations Mark Brown
2020-01-07 14:44   ` Will Deacon
2020-01-07 16:45     ` Mark Brown
2020-01-06 19:58 ` [PATCH 2/3] arm64: lib: Use modern annotations for assembly functions Mark Brown
2020-01-07 14:44   ` Will Deacon
2020-01-07 17:47     ` Mark Brown
2020-01-08 12:29       ` Will Deacon
2020-01-10 16:56         ` Jiri Slaby [this message]
2020-01-15 18:43           ` Will Deacon
2020-01-06 19:58 ` [PATCH 3/3] arm64: mm: " Mark Brown
2020-01-07 14:43   ` Will Deacon
2020-01-07 16:42     ` Mark Brown
2020-01-08 12:17       ` Will Deacon
2020-01-08 13:50         ` Mark Brown
2020-01-08 14:56           ` Will Deacon

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=c241898d-3a0f-4356-0f2c-7d18ee35f45c@suse.com \
    --to=jslaby@suse.com \
    --cc=broonie@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=will@kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.