* [PATCH] x86: Alias memset to __builtin_memset.
[not found] <20200323114207.222412-1-courbet@google.com>
@ 2020-03-26 12:38 ` Clement Courbet
2020-03-26 17:18 ` Nick Desaulniers
` (2 more replies)
0 siblings, 3 replies; 4+ messages in thread
From: Clement Courbet @ 2020-03-26 12:38 UTC (permalink / raw)
Cc: x86, Kees Cook, Borislav Petkov, Greg Kroah-Hartman,
H. Peter Anvin, Nick Desaulniers, linux-kernel, clang-built-linux,
Ingo Molnar, Paul Mackerras, Clement Courbet, Joe Perches,
Bernd Petrovitsch, Nathan Chancellor, linuxppc-dev,
Thomas Gleixner, Allison Randal
I discussed with the original authors who added freestanding to our
build. It turns out that it was added globally but this was just to
to workaround powerpc not compiling under clang, but they felt the
fix was appropriate globally.
Now Nick has dug up https://lkml.org/lkml/2019/8/29/1300, which
advises against freestanding. Also, I've did some research and
discovered that the original reason for using freestanding for
powerpc has been fixed here:
https://lore.kernel.org/linuxppc-dev/20191119045712.39633-3-natechancellor@gmail.com/
I'm going to remove -ffreestanding from downstream, so we don't really need
this anymore, sorry for waisting people's time.
I wonder if the freestanding fix from the aforementioned patch is really needed
though. I think that clang is actually right to point out the issue.
I don't see any reason why setjmp()/longjmp() are declared as taking longs
rather than ints. The implementation looks like it only ever propagates the
value (in longjmp) or sets it to 1 (in setjmp), and we only ever call longjmp
with integer parameters. But I'm not a PowerPC expert, so I might
be misreading the code.
So it seems that we could just remove freestanding altogether and rewrite the
code to:
diff --git a/arch/powerpc/include/asm/setjmp.h b/arch/powerpc/include/asm/setjmp.h
index 279d03a1eec6..7941ae68fe21 100644
--- a/arch/powerpc/include/asm/setjmp.h
+++ b/arch/powerpc/include/asm/setjmp.h
@@ -12,7 +12,9 @@
#define JMP_BUF_LEN 23
-extern long setjmp(long *);
-extern void longjmp(long *, long);
+typedef long * jmp_buf;
+
+extern int setjmp(jmp_buf);
+extern void longjmp(jmp_buf, int);
I'm happy to send a patch for this, and get rid of more -ffreestanding.
Opinions ?
^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: [PATCH] x86: Alias memset to __builtin_memset.
2020-03-26 12:38 ` [PATCH] x86: Alias memset to __builtin_memset Clement Courbet
@ 2020-03-26 17:18 ` Nick Desaulniers
2020-03-27 4:06 ` Michael Ellerman
2020-03-27 17:12 ` Segher Boessenkool
2 siblings, 0 replies; 4+ messages in thread
From: Nick Desaulniers @ 2020-03-26 17:18 UTC (permalink / raw)
To: Clement Courbet
Cc: maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT), Kees Cook,
Borislav Petkov, Greg Kroah-Hartman, H. Peter Anvin, LKML,
clang-built-linux, Ingo Molnar, Paul Mackerras, Joe Perches,
Bernd Petrovitsch, Nathan Chancellor, linuxppc-dev,
Thomas Gleixner, Allison Randal
On Thu, Mar 26, 2020 at 5:38 AM Clement Courbet <courbet@google.com> wrote:
>
> I discussed with the original authors who added freestanding to our
> build. It turns out that it was added globally but this was just to
> to workaround powerpc not compiling under clang, but they felt the
> fix was appropriate globally.
>
> Now Nick has dug up https://lkml.org/lkml/2019/8/29/1300, which
> advises against freestanding. Also, I've did some research and
> discovered that the original reason for using freestanding for
> powerpc has been fixed here:
> https://lore.kernel.org/linuxppc-dev/20191119045712.39633-3-natechancellor@gmail.com/
>
> I'm going to remove -ffreestanding from downstream, so we don't really need
> this anymore, sorry for waisting people's time.
>
> I wonder if the freestanding fix from the aforementioned patch is really needed
> though. I think that clang is actually right to point out the issue.
> I don't see any reason why setjmp()/longjmp() are declared as taking longs
> rather than ints. The implementation looks like it only ever propagates the
> value (in longjmp) or sets it to 1 (in setjmp), and we only ever call longjmp
> with integer parameters. But I'm not a PowerPC expert, so I might
> be misreading the code.
>
>
> So it seems that we could just remove freestanding altogether and rewrite the
> code to:
>
> diff --git a/arch/powerpc/include/asm/setjmp.h b/arch/powerpc/include/asm/setjmp.h
> index 279d03a1eec6..7941ae68fe21 100644
> --- a/arch/powerpc/include/asm/setjmp.h
> +++ b/arch/powerpc/include/asm/setjmp.h
> @@ -12,7 +12,9 @@
>
> #define JMP_BUF_LEN 23
> -extern long setjmp(long *);
> -extern void longjmp(long *, long);
> +typedef long * jmp_buf;
> +
> +extern int setjmp(jmp_buf);
> +extern void longjmp(jmp_buf, int);
>
> I'm happy to send a patch for this, and get rid of more -ffreestanding.
> Opinions ?
Yes, I think the above diff and additionally cleaning up
-ffreestanding from arch/powerpc/kernel/Makefile and
arch/powerpc/xmon/Makefile would be a much better approach. If that's
good enough to fix the warning, I kind of can't believe we didn't spot
that in the original code review!
Actually, the god awful warning was:
./arch/powerpc/include/asm/setjmp.h:10:13: error: declaration of
built-in function 'setjmp' requires the declaration of the 'jmp_buf'
type, commonly provided in the header <setjmp.h>.
[-Werror,-Wincomplete-setjmp-declaration]
extern long setjmp(long *) __attribute__((returns_twice));
^
So jmp_buf was missing, wasn't used, but also the long vs int confusion.
I tested the above diff, all calls to setjmp under arch/powerpc/ just
compare the return value against 0. Callers of longjmp just pass 1
for the final parameter. So the above changes should be no functional
change.
--
Thanks,
~Nick Desaulniers
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] x86: Alias memset to __builtin_memset.
2020-03-26 12:38 ` [PATCH] x86: Alias memset to __builtin_memset Clement Courbet
2020-03-26 17:18 ` Nick Desaulniers
@ 2020-03-27 4:06 ` Michael Ellerman
2020-03-27 17:12 ` Segher Boessenkool
2 siblings, 0 replies; 4+ messages in thread
From: Michael Ellerman @ 2020-03-27 4:06 UTC (permalink / raw)
To: Clement Courbet
Cc: Kees Cook, Borislav Petkov, Greg Kroah-Hartman, x86,
Nick Desaulniers, linux-kernel, clang-built-linux, Ingo Molnar,
Paul Mackerras, Clement Courbet, H. Peter Anvin, Joe Perches,
Bernd Petrovitsch, Nathan Chancellor, linuxppc-dev,
Thomas Gleixner, Allison Randal
Clement Courbet <courbet@google.com> writes:
> I discussed with the original authors who added freestanding to our
> build. It turns out that it was added globally but this was just to
> to workaround powerpc not compiling under clang, but they felt the
> fix was appropriate globally.
>
> Now Nick has dug up https://lkml.org/lkml/2019/8/29/1300, which
> advises against freestanding. Also, I've did some research and
> discovered that the original reason for using freestanding for
> powerpc has been fixed here:
> https://lore.kernel.org/linuxppc-dev/20191119045712.39633-3-natechancellor@gmail.com/
>
> I'm going to remove -ffreestanding from downstream, so we don't really need
> this anymore, sorry for waisting people's time.
>
> I wonder if the freestanding fix from the aforementioned patch is really needed
> though. I think that clang is actually right to point out the issue.
> I don't see any reason why setjmp()/longjmp() are declared as taking longs
> rather than ints. The implementation looks like it only ever propagates the
> value (in longjmp) or sets it to 1 (in setjmp), and we only ever call longjmp
> with integer parameters. But I'm not a PowerPC expert, so I might
> be misreading the code.
>
>
> So it seems that we could just remove freestanding altogether and rewrite the
> code to:
>
> diff --git a/arch/powerpc/include/asm/setjmp.h b/arch/powerpc/include/asm/setjmp.h
> index 279d03a1eec6..7941ae68fe21 100644
> --- a/arch/powerpc/include/asm/setjmp.h
> +++ b/arch/powerpc/include/asm/setjmp.h
> @@ -12,7 +12,9 @@
>
> #define JMP_BUF_LEN 23
> -extern long setjmp(long *);
> -extern void longjmp(long *, long);
> +typedef long * jmp_buf;
> +
> +extern int setjmp(jmp_buf);
> +extern void longjmp(jmp_buf, int);
>
> I'm happy to send a patch for this, and get rid of more -ffreestanding.
> Opinions ?
If it works then it looks like a much better fix than using -ffreestanding.
Please submit a patch with a change log etc. and I'd be happy to merge
it.
cheers
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] x86: Alias memset to __builtin_memset.
2020-03-26 12:38 ` [PATCH] x86: Alias memset to __builtin_memset Clement Courbet
2020-03-26 17:18 ` Nick Desaulniers
2020-03-27 4:06 ` Michael Ellerman
@ 2020-03-27 17:12 ` Segher Boessenkool
2 siblings, 0 replies; 4+ messages in thread
From: Segher Boessenkool @ 2020-03-27 17:12 UTC (permalink / raw)
To: Clement Courbet
Cc: x86, Kees Cook, Borislav Petkov, Greg Kroah-Hartman,
H. Peter Anvin, Nick Desaulniers, linux-kernel, clang-built-linux,
Ingo Molnar, Paul Mackerras, Joe Perches, Bernd Petrovitsch,
Nathan Chancellor, linuxppc-dev, Thomas Gleixner, Allison Randal
Hi!
On Thu, Mar 26, 2020 at 01:38:39PM +0100, Clement Courbet wrote:
> --- a/arch/powerpc/include/asm/setjmp.h
> +++ b/arch/powerpc/include/asm/setjmp.h
> @@ -12,7 +12,9 @@
>
> #define JMP_BUF_LEN 23
> -extern long setjmp(long *);
> -extern void longjmp(long *, long);
> +typedef long * jmp_buf;
> +
> +extern int setjmp(jmp_buf);
> +extern void longjmp(jmp_buf, int);
>
> I'm happy to send a patch for this, and get rid of more -ffreestanding.
> Opinions ?
Pedantically, jmp_buf should be an array type. But, this will probably
work fine, and it certainly is better than what we had before.
You could do
typedef long jmp_buf[JMP_BUF_LEN];
perhaps?
Thanks,
Segher
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2020-03-27 17:16 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20200323114207.222412-1-courbet@google.com>
2020-03-26 12:38 ` [PATCH] x86: Alias memset to __builtin_memset Clement Courbet
2020-03-26 17:18 ` Nick Desaulniers
2020-03-27 4:06 ` Michael Ellerman
2020-03-27 17:12 ` Segher Boessenkool
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).