Dear stable kernel maintainers, Please consider accepting the following backport to 5.4 and 4.19 of commit 4d6ffa27b8e5 ("x86/lib: Change .weak to SYM_FUNC_START_WEAK for arch/x86/lib/mem*_64.S"), attached.
The patch to 5.4 had a conflict due to 5.4 missing upstream commit e9b9d020c487 ("x86/asm: Annotate aliases") which first landed in v5.5-rc1.
The patch to 4.19 had a conflict due to 4.19 missing the above commit and ffedeeb780dc ("linkage: Introduce new macros for assembler symbols") which also first landed in v5.5-rc1 but was backported to linux-5.4.y as commit 840d8c9b3e5f ("linkage: Introduce new macros for assembler symbols") which shipped in v5.4.76.
This patch fixes a build error from clang's assembler when building with Clang-12, which now errors when symbols are redeclared with different bindings. We're using clang's assembler in Android and ChromeOS for 4.19+.
Jiri, would you mind reviewing the 4.19 patch (or both)? It simply open codes what the upstream macros would expand to; this can be and was observed from running: $ make ... arch/x86/lib/memmove_64.s (ie. lowercase s, to invoke the C preprocessor on the uppercase .S file)
See also: https://github.com/ClangBuiltLinux/linux/issues/1190.
On 09. 12. 20, 1:12, Nick Desaulniers wrote:
Dear stable kernel maintainers, Please consider accepting the following backport to 5.4 and 4.19 of commit 4d6ffa27b8e5 ("x86/lib: Change .weak to SYM_FUNC_START_WEAK for arch/x86/lib/mem*_64.S"), attached.
The patch to 5.4 had a conflict due to 5.4 missing upstream commit e9b9d020c487 ("x86/asm: Annotate aliases") which first landed in v5.5-rc1.
The patch to 4.19 had a conflict due to 4.19 missing the above commit and ffedeeb780dc ("linkage: Introduce new macros for assembler symbols") which also first landed in v5.5-rc1 but was backported to linux-5.4.y as commit 840d8c9b3e5f ("linkage: Introduce new macros for assembler symbols") which shipped in v5.4.76.
This patch fixes a build error from clang's assembler when building with Clang-12, which now errors when symbols are redeclared with different bindings. We're using clang's assembler in Android and ChromeOS for 4.19+.
Jiri, would you mind reviewing the 4.19 patch (or both)? It simply open codes what the upstream macros would expand to; this can be and was observed from running:
You don't have to touch (expand) __memcpy, __memmove, and __memset, right?
thanks,
On 09. 12. 20, 8:20, Jiri Slaby wrote:
On 09. 12. 20, 1:12, Nick Desaulniers wrote:
Dear stable kernel maintainers, Please consider accepting the following backport to 5.4 and 4.19 of commit 4d6ffa27b8e5 ("x86/lib: Change .weak to SYM_FUNC_START_WEAK for arch/x86/lib/mem*_64.S"), attached.
The patch to 5.4 had a conflict due to 5.4 missing upstream commit e9b9d020c487 ("x86/asm: Annotate aliases") which first landed in v5.5-rc1.
The patch to 4.19 had a conflict due to 4.19 missing the above commit and ffedeeb780dc ("linkage: Introduce new macros for assembler symbols") which also first landed in v5.5-rc1 but was backported to linux-5.4.y as commit 840d8c9b3e5f ("linkage: Introduce new macros for assembler symbols") which shipped in v5.4.76.
This patch fixes a build error from clang's assembler when building with Clang-12, which now errors when symbols are redeclared with different bindings. We're using clang's assembler in Android and ChromeOS for 4.19+.
Jiri, would you mind reviewing the 4.19 patch (or both)? It simply open codes what the upstream macros would expand to; this can be and was observed from running:
You don't have to touch (expand) __memcpy, __memmove, and __memset, right?
Also, no need for doubled p2align.
thanks,
On Tue, Dec 8, 2020 at 11:21 PM Jiri Slaby jirislaby@kernel.org wrote:
On 09. 12. 20, 8:20, Jiri Slaby wrote:
On 09. 12. 20, 1:12, Nick Desaulniers wrote:
Dear stable kernel maintainers, Please consider accepting the following backport to 5.4 and 4.19 of commit 4d6ffa27b8e5 ("x86/lib: Change .weak to SYM_FUNC_START_WEAK for arch/x86/lib/mem*_64.S"), attached.
Also, first landed in v5.10-rc3. Exists in v5.9.7 as 305da744c138487864a46b2fb0bd7cf54e1e03b4.
The patch to 5.4 had a conflict due to 5.4 missing upstream commit e9b9d020c487 ("x86/asm: Annotate aliases") which first landed in v5.5-rc1.
The patch to 4.19 had a conflict due to 4.19 missing the above commit and ffedeeb780dc ("linkage: Introduce new macros for assembler symbols") which also first landed in v5.5-rc1 but was backported to linux-5.4.y as commit 840d8c9b3e5f ("linkage: Introduce new macros for assembler symbols") which shipped in v5.4.76.
This patch fixes a build error from clang's assembler when building with Clang-12, which now errors when symbols are redeclared with different bindings. We're using clang's assembler in Android and ChromeOS for 4.19+.
Jiri, would you mind reviewing the 4.19 patch (or both)? It simply open codes what the upstream macros would expand to; this can be and was observed from running:
You don't have to touch (expand) __memcpy, __memmove, and __memset, right?
Sure, attached a v2. It's actually a little cleaner (smaller diffstat) that way.
Also, no need for doubled p2align.
eh, maybe, but 1. it's what SYM_FUNC_START expands to precisely; removing it would be (too) different from what upstream is doing IMO. 2. it's obviously doubled when in v1 I was expanding the __ prefixed symbols as well; not so obvious in v2. 3. the order of __ prefixed symbols differs between these three; I'd rather not rely on the order or have to reorder them to get the initial symbol realigned; specifying the alignment for both seems safer to me.
So I haven't included that suggestion in v2, but please feel free to convince me otherwise if you feel strongly.
Thanks for taking the time to review. I appreciate it.
On Thu, Dec 10, 2020 at 01:15:29PM -0800, Nick Desaulniers wrote:
On Tue, Dec 8, 2020 at 11:21 PM Jiri Slaby jirislaby@kernel.org wrote:
On 09. 12. 20, 8:20, Jiri Slaby wrote:
On 09. 12. 20, 1:12, Nick Desaulniers wrote:
Dear stable kernel maintainers, Please consider accepting the following backport to 5.4 and 4.19 of commit 4d6ffa27b8e5 ("x86/lib: Change .weak to SYM_FUNC_START_WEAK for arch/x86/lib/mem*_64.S"), attached.
Also, first landed in v5.10-rc3. Exists in v5.9.7 as 305da744c138487864a46b2fb0bd7cf54e1e03b4.
The patch to 5.4 had a conflict due to 5.4 missing upstream commit e9b9d020c487 ("x86/asm: Annotate aliases") which first landed in v5.5-rc1.
The patch to 4.19 had a conflict due to 4.19 missing the above commit and ffedeeb780dc ("linkage: Introduce new macros for assembler symbols") which also first landed in v5.5-rc1 but was backported to linux-5.4.y as commit 840d8c9b3e5f ("linkage: Introduce new macros for assembler symbols") which shipped in v5.4.76.
This patch fixes a build error from clang's assembler when building with Clang-12, which now errors when symbols are redeclared with different bindings. We're using clang's assembler in Android and ChromeOS for 4.19+.
Jiri, would you mind reviewing the 4.19 patch (or both)? It simply open codes what the upstream macros would expand to; this can be and was observed from running:
You don't have to touch (expand) __memcpy, __memmove, and __memset, right?
Sure, attached a v2. It's actually a little cleaner (smaller diffstat) that way.
Applied, thanks.
greg k-h
linux-stable-mirror@lists.linaro.org
-
Greg KH -
Jiri Slaby -
Nick Desaulniers