[Linux-kernel-mentees] Fwd: [PATCH v4] x86/entry: emit a symbol for register restoring thunk

[Lukas Bulwahn <lukas.bulwahn@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2612 bytes --]

Dwaipayan and Aditya, here is another candidate for a checkpatch rule.

Lukas

---------- Forwarded message ---------
From: Mark Brown <broonie@kernel.org>
Date: Tue, Jan 12, 2021 at 10:02 PM
Subject: Re: [PATCH v4] x86/entry: emit a symbol for register restoring thunk
To: Nick Desaulniers <ndesaulniers@google.com>
Cc: Andy Lutomirski <luto@kernel.org>, Thomas Gleixner
<tglx@linutronix.de>, Ingo Molnar <mingo@redhat.com>, Borislav Petkov
<bp@alien8.de>, Fangrui Song <maskray@google.com>, Arnd Bergmann
<arnd@arndb.de>, Josh Poimboeuf <jpoimboe@redhat.com>, Jonathan Corbet
<corbet@lwn.net>, <x86@kernel.org>, H. Peter Anvin <hpa@zytor.com>,
Nathan Chancellor <natechancellor@gmail.com>, Miguel Ojeda
<ojeda@kernel.org>, Jiri Slaby <jirislaby@kernel.org>, Joe Perches
<joe@perches.com>, <linux-doc@vger.kernel.org>,
<linux-kernel@vger.kernel.org>, <clang-built-linux@googlegroups.com>


On Tue, Jan 12, 2021 at 11:46:24AM -0800, Nick Desaulniers wrote:

This:

> when building with LLVM_IAS=1 (Clang's integrated assembler). Josh
> notes:

>   So basically, you can use an .L symbol *inside* a function or a code
>   segment, you just can't use the .L symbol to contain the code using a
>   SYM_*_START/END annotation pair.

is a stronger statement than this:

> +  Developers should avoid using local symbol names that are prefixed with
> +  ``.L``, as this has special meaning for the assembler; a symbol entry will
> +  not be emitted into the symbol table. This can prevent ``objtool`` from
> +  generating correct unwind info. Symbols with STB_LOCAL binding may still be
> +  used, and ``.L`` prefixed local symbol names are still generally useable
> +  within a function, but ``.L`` prefixed local symbol names should not be used
> +  to denote the beginning or end of code regions via
> +  ``SYM_CODE_START_LOCAL``/``SYM_CODE_END``.

and seems more what I'd expect - SYM_FUNC* is also affected for example.
Even though other usages are probably not very likely it seems better to
keep the stronger statement in case someone comes up with one, and to
stop anyone spending time wondering why only SYM_CODE_START_LOCAL is
affected.

This also looks like a good candiate for a checkpatch rule, but that can
be done separately of course.

--
You received this message because you are subscribed to the Google
Groups "Clang Built Linux" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to clang-built-linux+unsubscribe@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/clang-built-linux/20210112210154.GI4646%40sirena.org.uk.

[-- Attachment #2: signature.asc --]
[-- Type: text/plain, Size: 499 bytes --]

-----BEGIN PGP SIGNATURE-----

iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAl/+DkEACgkQJNaLcl1U
h9Cq7wf/T25FXiQQZ1vqQuvuSs9y7UidITjNn00or2An/9AZvjd7fNSIGitE6JZF
ulLa3Dnm6DnJ8IHxCom/f9HA0Bhqduottun00gPpRE4yYnc6I6rs4+jD3D3yaM+e
P48KYy2zaNF6Xgud3wdMdBWrO6wHbpk/FtrGu9myxKXbPoaWXCc/2JO+lQGHy2Ld
stRoPLzuNHGsqiiQyQVFUCJcva6y2q5UTYqWG21loFirQ0khEI1aHwVuifeddpjE
JamhRqQhmlTD8qRrnf8c4iVj6oexQsKzjOKkaKX2qpyYhK8bxdgvG8r0kwJfnuZM
LObeotMsynR86MF2K/fVFTw7r4fXMw==
=H9dS
-----END PGP SIGNATURE-----

[-- Attachment #3: Type: text/plain, Size: 201 bytes --]

_______________________________________________
Linux-kernel-mentees mailing list
Linux-kernel-mentees@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/linux-kernel-mentees