| Message ID | 20180910060455.20409-1-stefan@agner.ch (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | include/linux/compiler-clang.h: define __naked | expand |
On Mon, Sep 10, 2018 at 8:05 AM Stefan Agner <stefan@agner.ch> wrote: > > ARM32 arch code uses the __naked attribute. This has previously been > defined in include/linux/compiler-gcc.h, which is no longer included > for Clang. Define __naked for Clang. Conservatively add all attributes > previously used (and supported by Clang). > > This fixes compile errors when building ARM32 using Clang: > arch/arm/mach-exynos/mcpm-exynos.c:193:13: error: variable has incomplete type 'void' > static void __naked exynos_pm_power_up_setup(unsigned int affinity_level) > ^ > > Fixes: 815f0ddb346c ("include/linux/compiler*.h: make compiler-*.h mutually exclusive") > Signed-off-by: Stefan Agner <stefan@agner.ch> > +/* > + * ARM32 is currently the only user of __naked supported by Clang. Follow > + * gcc: Do not trace naked functions and make sure they don't get inlined. > + */ > +#define __naked __attribute__((naked)) noinline notrace > + Please see patches 5 and 6 of the series that Miguel posted: https://lore.kernel.org/lkml/20180908212459.19736-6-miguel.ojeda.sandonis@gmail.com/ I suppose we want the patch to fix clang build as soon as possible though, and follow up with the cleanup for the next merge window, right? Arnd
On Mon, Sep 10, 2018 at 5:14 AM Arnd Bergmann <arnd@arndb.de> wrote: > > On Mon, Sep 10, 2018 at 8:05 AM Stefan Agner <stefan@agner.ch> wrote: > > > > ARM32 arch code uses the __naked attribute. This has previously been > > defined in include/linux/compiler-gcc.h, which is no longer included > > for Clang. Define __naked for Clang. Conservatively add all attributes > > previously used (and supported by Clang). > > > > This fixes compile errors when building ARM32 using Clang: > > arch/arm/mach-exynos/mcpm-exynos.c:193:13: error: variable has incomplete type 'void' > > static void __naked exynos_pm_power_up_setup(unsigned int affinity_level) > > ^ > > > > Fixes: 815f0ddb346c ("include/linux/compiler*.h: make compiler-*.h mutually exclusive") > > Signed-off-by: Stefan Agner <stefan@agner.ch> Cool, thanks for this patch! I'll admit I need to start testing more architectures with Clang. > > > +/* > > + * ARM32 is currently the only user of __naked supported by Clang. Follow > > + * gcc: Do not trace naked functions and make sure they don't get inlined. > > + */ > > +#define __naked __attribute__((naked)) noinline notrace > > + > > Please see patches 5 and 6 of the series that Miguel posted: > > https://lore.kernel.org/lkml/20180908212459.19736-6-miguel.ojeda.sandonis@gmail.com/ Yes, I'd prefer those 2 patches. > > I suppose we want the patch to fix clang build as soon as possible though, > and follow up with the cleanup for the next merge window, right? Can we take Miguel's two patches from above in the ARM tree, since this attribute is only used on ARM, IIUC?
Hi Arnd, Nick, Stefan, On Mon, Sep 10, 2018 at 2:14 PM, Arnd Bergmann <arnd@arndb.de> wrote: > On Mon, Sep 10, 2018 at 8:05 AM Stefan Agner <stefan@agner.ch> wrote: >> >> ARM32 arch code uses the __naked attribute. This has previously been >> defined in include/linux/compiler-gcc.h, which is no longer included >> for Clang. Define __naked for Clang. Conservatively add all attributes >> previously used (and supported by Clang). >> >> This fixes compile errors when building ARM32 using Clang: >> arch/arm/mach-exynos/mcpm-exynos.c:193:13: error: variable has incomplete type 'void' >> static void __naked exynos_pm_power_up_setup(unsigned int affinity_level) >> ^ >> >> Fixes: 815f0ddb346c ("include/linux/compiler*.h: make compiler-*.h mutually exclusive") >> Signed-off-by: Stefan Agner <stefan@agner.ch> > >> +/* >> + * ARM32 is currently the only user of __naked supported by Clang. Follow >> + * gcc: Do not trace naked functions and make sure they don't get inlined. >> + */ >> +#define __naked __attribute__((naked)) noinline notrace >> + > > Please see patches 5 and 6 of the series that Miguel posted: > > https://lore.kernel.org/lkml/20180908212459.19736-6-miguel.ojeda.sandonis@gmail.com/ > > I suppose we want the patch to fix clang build as soon as possible though, > and follow up with the cleanup for the next merge window, right? Not sure what the plans of Linus et. al. are, if they have any; but that would be a safe bet. In case they want to speed this up and put the entire series into v4.19 (instead of the two patches), I have done a binary & objdump diff between -rc2 and v4 (based on -rc2) on all object files (with UTS_RELEASE fixed to avoid some differences). In a x86_64 tinyconfig with gcc 7.3, the differences I found are: $ ./compare.py linux-rc2 linux-v4 [2018-09-12 06:16:39,483] [INFO] [arch/x86/boot/compressed/piggy.o] Binary diff (use 'bash -c "cmp linux-rc2/arch/x86/boot/compressed/piggy.o linux-v4/arch/x86/boot/compressed/piggy.o"' to replicate) [2018-09-12 06:16:39,606] [INFO] [arch/x86/boot/header.o] Binary diff (use 'bash -c "cmp linux-rc2/arch/x86/boot/header.o linux-v4/arch/x86/boot/header.o"' to replicate) [2018-09-12 06:16:39,659] [INFO] [arch/x86/boot/version.o] Binary diff (use 'bash -c "cmp linux-rc2/arch/x86/boot/version.o linux-v4/arch/x86/boot/version.o"' to replicate) [2018-09-12 06:16:40,483] [INFO] [init/version.o] Binary diff (use 'bash -c "cmp linux-rc2/init/version.o linux-v4/init/version.o"' to replicate) I will do a bigger one tomorrow or so and see if there are any important differences. Regardless of what we do, I will send the __naked patches separately as well (requested by Nick on GitHub). Cheers, Miguel
Hi again, On Wed, Sep 12, 2018 at 6:19 AM, Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> wrote: > > I will do a bigger one tomorrow or so and see if there are any > important differences. Regardless of what we do, I will send the > __naked patches separately as well (requested by Nick on GitHub). So I did a comparison with a full allyesconfig between -rc2 and -rc2 + v4. I find quite a lot binary differences, but not a single objdump -d difference (object file by object file) just by fixing UTS_RELEASE to the same value, so I guess that is a very good sign in case someone wants to pick the entire series sooner than expected. Regardless, I will send the separate __naked patches. I should note that, at some point in one of my allyesconfig builds I got this: UPD include/generated/compile.h CC init/version.o AR init/built-in.a AR built-in.a LD vmlinux.o MODPOST vmlinux.o ld: drivers/edac/amd64_edac.o(.text+0x200031d2): reloc against `__asan_load4_noabort': error 4 ld: final link failed: Nonrepresentable section on output Makefile:1035: recipe for target 'vmlinux' failed make: *** [vmlinux] Error 1 Running make (without cleaning) didn't reproduce it, and the other allyesconfig builds didn't suffer any problem either. Maybe my hardware is failing, but I wanted to let you know nevertheless. Cheers, Miguel
On Wed, Sep 12, 2018 at 9:03 PM Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> wrote: > > Hi again, > > On Wed, Sep 12, 2018 at 6:19 AM, Miguel Ojeda > <miguel.ojeda.sandonis@gmail.com> wrote: > > > > I will do a bigger one tomorrow or so and see if there are any > > important differences. Regardless of what we do, I will send the > > __naked patches separately as well (requested by Nick on GitHub). > > So I did a comparison with a full allyesconfig between -rc2 and -rc2 + > v4. I find quite a lot binary differences, but not a single objdump -d > difference (object file by object file) just by fixing UTS_RELEASE to > the same value, so I guess that is a very good sign in case someone > wants to pick the entire series sooner than expected. Regardless, I > will send the separate __naked patches. > > I should note that, at some point in one of my allyesconfig builds I got this: > > UPD include/generated/compile.h > CC init/version.o > AR init/built-in.a > AR built-in.a > LD vmlinux.o > MODPOST vmlinux.o > ld: drivers/edac/amd64_edac.o(.text+0x200031d2): reloc against > `__asan_load4_noabort': error 4 > ld: final link failed: Nonrepresentable section on output > Makefile:1035: recipe for target 'vmlinux' failed > make: *** [vmlinux] Error 1 + Dmitry for the KASAN error (Andrey was already cc'ed) > > Running make (without cleaning) didn't reproduce it, and the other > allyesconfig builds didn't suffer any problem either. Maybe my > hardware is failing, but I wanted to let you know nevertheless. > > Cheers, > Miguel
diff --git a/include/linux/compiler-clang.h b/include/linux/compiler-clang.h index b1ce500fe8b3..a593e3ac0720 100644 --- a/include/linux/compiler-clang.h +++ b/include/linux/compiler-clang.h @@ -23,6 +23,12 @@ #define __no_sanitize_address __attribute__((no_sanitize("address"))) +/* + * ARM32 is currently the only user of __naked supported by Clang. Follow + * gcc: Do not trace naked functions and make sure they don't get inlined. + */ +#define __naked __attribute__((naked)) noinline notrace + /* * Not all versions of clang implement the the type-generic versions * of the builtin overflow checkers. Fortunately, clang implements
ARM32 arch code uses the __naked attribute. This has previously been defined in include/linux/compiler-gcc.h, which is no longer included for Clang. Define __naked for Clang. Conservatively add all attributes previously used (and supported by Clang). This fixes compile errors when building ARM32 using Clang: arch/arm/mach-exynos/mcpm-exynos.c:193:13: error: variable has incomplete type 'void' static void __naked exynos_pm_power_up_setup(unsigned int affinity_level) ^ Fixes: 815f0ddb346c ("include/linux/compiler*.h: make compiler-*.h mutually exclusive") Signed-off-by: Stefan Agner <stefan@agner.ch> --- include/linux/compiler-clang.h | 6 ++++++ 1 file changed, 6 insertions(+)