2018-09-10 06:06:37

by Stefan Agner

[permalink] [raw]
Subject: [PATCH] include/linux/compiler-clang.h: define __naked

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 <[email protected]>
---
include/linux/compiler-clang.h | 6 ++++++
1 file changed, 6 insertions(+)

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
--
2.18.0



2018-09-10 12:16:19

by Arnd Bergmann

[permalink] [raw]
Subject: Re: [PATCH] include/linux/compiler-clang.h: define __naked

On Mon, Sep 10, 2018 at 8:05 AM Stefan Agner <[email protected]> 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 <[email protected]>

> +/*
> + * 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/[email protected]/

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

2018-09-10 16:53:26

by Nick Desaulniers

[permalink] [raw]
Subject: Re: [PATCH] include/linux/compiler-clang.h: define __naked

On Mon, Sep 10, 2018 at 5:14 AM Arnd Bergmann <[email protected]> wrote:
>
> On Mon, Sep 10, 2018 at 8:05 AM Stefan Agner <[email protected]> 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 <[email protected]>

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/[email protected]/

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?

--
Thanks,
~Nick Desaulniers

2018-09-12 04:19:52

by Miguel Ojeda

[permalink] [raw]
Subject: Re: [PATCH] include/linux/compiler-clang.h: define __naked

Hi Arnd, Nick, Stefan,

On Mon, Sep 10, 2018 at 2:14 PM, Arnd Bergmann <[email protected]> wrote:
> On Mon, Sep 10, 2018 at 8:05 AM Stefan Agner <[email protected]> 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 <[email protected]>
>
>> +/*
>> + * 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/[email protected]/
>
> 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

2018-09-13 04:03:37

by Miguel Ojeda

[permalink] [raw]
Subject: Re: [PATCH] include/linux/compiler-clang.h: define __naked

Hi again,

On Wed, Sep 12, 2018 at 6:19 AM, Miguel Ojeda
<[email protected]> 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

2018-09-13 22:22:50

by Nick Desaulniers

[permalink] [raw]
Subject: Re: [PATCH] include/linux/compiler-clang.h: define __naked

On Wed, Sep 12, 2018 at 9:03 PM Miguel Ojeda
<[email protected]> wrote:
>
> Hi again,
>
> On Wed, Sep 12, 2018 at 6:19 AM, Miguel Ojeda
> <[email protected]> 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



--
Thanks,
~Nick Desaulniers