Debian started to build the gcc with --enable-default-pie by default so the
kernel build ends before it starts properly with:
|kernel/bounds.c:1:0: error: code model kernel does not support PIC mode
Is this okay or do we want some kind of check to see if -fno-PIE is supported?
It is mentioned in the 4.4.7 gcc manpage is it is not *that* new :)
Signed-off-by: Sebastian Andrzej Siewior <[email protected]>
---
Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Makefile b/Makefile
index bf6e44a421df..97296d66b586 100644
--- a/Makefile
+++ b/Makefile
@@ -398,7 +398,7 @@ KBUILD_CPPFLAGS := -D__KERNEL__
KBUILD_CFLAGS := -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs \
-fno-strict-aliasing -fno-common \
-Werror-implicit-function-declaration \
- -Wno-format-security \
+ -Wno-format-security -fno-PIE \
-std=gnu89
KBUILD_AFLAGS_KERNEL :=
--
2.9.3
On Fri, Oct 21, 2016 at 01:16:00PM +0200, Sebastian Andrzej Siewior wrote:
> Debian started to build the gcc with --enable-default-pie by default
To be exact: this is since gcc-6 6.2.0-7 dated Tue, 18 Oct 2016 13:53:00 +0200
on amd64 arm64 armel armhf i386 mips mipsel mips64el ppc64el s390x.
> so the kernel build ends before it starts properly with:
> |kernel/bounds.c:1:0: error: code model kernel does not support PIC mode
>
> Is this okay or do we want some kind of check to see if -fno-PIE is supported?
> It is mentioned in the 4.4.7 gcc manpage is it is not *that* new :)
A naive "git log -Sno-PIE" on gcc sources shows commit 3e7f6cce[1] from Feb
2004, and as gcc automatically supports no-XXX whenever XXX is added, it
appears the option is older than that.
> Signed-off-by: Sebastian Andrzej Siewior <[email protected]>
> ---
> Makefile | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Makefile b/Makefile
> index bf6e44a421df..97296d66b586 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -398,7 +398,7 @@ KBUILD_CPPFLAGS := -D__KERNEL__
> KBUILD_CFLAGS := -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs \
> -fno-strict-aliasing -fno-common \
> -Werror-implicit-function-declaration \
> - -Wno-format-security \
> + -Wno-format-security -fno-PIE \
> -std=gnu89
>
> KBUILD_AFLAGS_KERNEL :=
> --
> 2.9.3
The patch works for me. I haven't done any but most trivial testing,
though.
[1]. Using the https://gcc.gnu.org/git/gcc.git git gateway, commit hashes
may be different elsewhere.
--
A MAP07 (Dead Simple) raspberry tincture recipe: 0.5l 95% alcohol, 1kg
raspberries, 0.4kg sugar; put into a big jar for 1 month. Filter out and
throw away the fruits (can dump them into a cake, etc), let the drink age
at least 3-6 months.
On 2016-10-21 23:21 +0200, Adam Borowski wrote:
> On Fri, Oct 21, 2016 at 01:16:00PM +0200, Sebastian Andrzej Siewior wrote:
>> Debian started to build the gcc with --enable-default-pie by default
>
> To be exact: this is since gcc-6 6.2.0-7 dated Tue, 18 Oct 2016 13:53:00 +0200
> on amd64 arm64 armel armhf i386 mips mipsel mips64el ppc64el s390x.
>
>> so the kernel build ends before it starts properly with:
>> |kernel/bounds.c:1:0: error: code model kernel does not support PIC mode
>>
>> Is this okay or do we want some kind of check to see if -fno-PIE is supported?
>> It is mentioned in the 4.4.7 gcc manpage is it is not *that* new :)
>
> A naive "git log -Sno-PIE" on gcc sources shows commit 3e7f6cce[1] from Feb
> 2004, and as gcc automatically supports no-XXX whenever XXX is added, it
> appears the option is older than that.
Testing on Debian 3.1 (sarge) chroot, it seems that GCC 3.4 is the first
release to accept -fPIE/-fno-PIE. Which could be a problem since
according to Documentation/Changes GCC 3.2 is sufficient to build the
kernel.
>> Signed-off-by: Sebastian Andrzej Siewior <[email protected]>
>> ---
>> Makefile | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/Makefile b/Makefile
>> index bf6e44a421df..97296d66b586 100644
>> --- a/Makefile
>> +++ b/Makefile
>> @@ -398,7 +398,7 @@ KBUILD_CPPFLAGS := -D__KERNEL__
>> KBUILD_CFLAGS := -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs \
>> -fno-strict-aliasing -fno-common \
>> -Werror-implicit-function-declaration \
>> - -Wno-format-security \
>> + -Wno-format-security -fno-PIE \
>> -std=gnu89
>>
>> KBUILD_AFLAGS_KERNEL :=
>> --
>> 2.9.3
>
> The patch works for me. I haven't done any but most trivial testing,
> though.
>
>
> [1]. Using the https://gcc.gnu.org/git/gcc.git git gateway, commit hashes
> may be different elsewhere.
Cheers,
Sven
On Sun, 2016-10-23 at 18:19 +0200, Sven Joachim wrote:
> On 2016-10-21 23:21 +0200, Adam Borowski wrote:
> > On Fri, Oct 21, 2016 at 01:16:00PM +0200, Sebastian Andrzej Siewior wrote:
> > > Debian started to build the gcc with --enable-default-pie by default
[]
> > > diff --git a/Makefile b/Makefile
[]
> > > @@ -398,7 +398,7 @@ KBUILD_CPPFLAGS := -D__KERNEL__
> > > KBUILD_CFLAGS := -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs \
> > > -fno-strict-aliasing -fno-common \
> > > -Werror-implicit-function-declaration \
> > > - -Wno-format-security \
> > > + -Wno-format-security -fno-PIE \
> > > -std=gnu89
I've used this here instead:
KBUILD_CFLAGS??+= $(call cc-option,-fno-pie)
On 2016-10-23 12:23 -0700, Joe Perches wrote:
> On Sun, 2016-10-23 at 18:19 +0200, Sven Joachim wrote:
>> On 2016-10-21 23:21 +0200, Adam Borowski wrote:
>> > On Fri, Oct 21, 2016 at 01:16:00PM +0200, Sebastian Andrzej Siewior wrote:
>> > > Debian started to build the gcc with --enable-default-pie by default
> []
>> > > diff --git a/Makefile b/Makefile
> []
>> > > @@ -398,7 +398,7 @@ KBUILD_CPPFLAGS := -D__KERNEL__
>> > > KBUILD_CFLAGS := -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs \
>> > > -fno-strict-aliasing -fno-common \
>> > > -Werror-implicit-function-declaration \
>> > > - -Wno-format-security \
>> > > + -Wno-format-security -fno-PIE \
>> > > -std=gnu89
>
> I've used this here instead:
>
> KBUILD_CFLAGS??+= $(call cc-option,-fno-pie)
Where exactly do you set that? I tried this patch:
--8<---------------cut here---------------start------------->8---
diff --git a/Makefile b/Makefile
index 93beca4..fde1e21 100644
--- a/Makefile
+++ b/Makefile
@@ -619,6 +619,7 @@ ARCH_AFLAGS :=
ARCH_CFLAGS :=
include arch/$(SRCARCH)/Makefile
+KBUILD_CFLAGS += $(call cc-option,-fno-pie,)
KBUILD_CFLAGS += $(call cc-option,-fno-delete-null-pointer-checks,)
KBUILD_CFLAGS += $(call cc-disable-warning,maybe-uninitialized,)
KBUILD_CFLAGS += $(call cc-disable-warning,frame-address,)
--8<---------------cut here---------------end--------------->8---
But make still fails with it. :-(
,----
| $ LANG=C make
| scripts/kconfig/conf --silentoldconfig Kconfig
| SYSTBL arch/x86/entry/syscalls/../../include/generated/asm/syscalls_32.h
| SYSHDR arch/x86/entry/syscalls/../../include/generated/asm/unistd_32_ia32.h
| SYSHDR arch/x86/entry/syscalls/../../include/generated/asm/unistd_64_x32.h
| SYSTBL arch/x86/entry/syscalls/../../include/generated/asm/syscalls_64.h
| SYSHDR arch/x86/entry/syscalls/../../include/generated/uapi/asm/unistd_32.h
| SYSHDR arch/x86/entry/syscalls/../../include/generated/uapi/asm/unistd_64.h
| SYSHDR arch/x86/entry/syscalls/../../include/generated/uapi/asm/unistd_x32.h
| HOSTCC arch/x86/tools/relocs_32.o
| HOSTCC arch/x86/tools/relocs_64.o
| HOSTCC arch/x86/tools/relocs_common.o
| HOSTLD arch/x86/tools/relocs
| CHK include/config/kernel.release
| UPD include/config/kernel.release
| Cannot use CONFIG_CC_STACKPROTECTOR_STRONG: -fstack-protector-strong available but compiler is broken
| Makefile:1066: recipe for target 'prepare-compiler-check' failed
| make: *** [prepare-compiler-check] Error 1
`----
Cheers,
Sven
On 2016-10-24 09:38:49 [+0200], Sven Joachim wrote:
>
> But make still fails with it. :-(
try setting CONFIG_CC_STACKPROTECTOR_NONE=y and please let me know if
the resulting kernel built with v3.2 gcc boots & works.
>
> Cheers,
> Sven
Sebastian
On Mon, 2016-10-24 at 09:38 +0200, Sven Joachim wrote:
> On 2016-10-23 12:23 -0700, Joe Perches wrote:
>
> > On Sun, 2016-10-23 at 18:19 +0200, Sven Joachim wrote:
> > > On 2016-10-21 23:21 +0200, Adam Borowski wrote:
> > > > On Fri, Oct 21, 2016 at 01:16:00PM +0200, Sebastian Andrzej Siewior wrote:
> > > > > Debian started to build the gcc with --enable-default-pie by default
> >
> > []
> > > > > diff --git a/Makefile b/Makefile
> >
> > []
> > > > > @@ -398,7 +398,7 @@ KBUILD_CPPFLAGS := -D__KERNEL__
> > > > > KBUILD_CFLAGS := -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs \
> > > > > -fno-strict-aliasing -fno-common \
> > > > > -Werror-implicit-function-declaration \
> > > > > - -Wno-format-security \
> > > > > + -Wno-format-security -fno-PIE \
> > > > > -std=gnu89
> >
> > I've used this here instead:
> >
> > KBUILD_CFLAGS??+= $(call cc-option,-fno-pie)
>
> Where exactly do you set that? I tried this patch:
>
> --8<---------------cut here---------------start------------->8---
> diff --git a/Makefile b/Makefile
> index 93beca4..fde1e21 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -619,6 +619,7 @@ ARCH_AFLAGS :=
> ARCH_CFLAGS :=
> include arch/$(SRCARCH)/Makefile
>
> +KBUILD_CFLAGS += $(call cc-option,-fno-pie,)
> KBUILD_CFLAGS += $(call cc-option,-fno-delete-null-pointer-checks,)
> KBUILD_CFLAGS += $(call cc-disable-warning,maybe-uninitialized,)
> KBUILD_CFLAGS += $(call cc-disable-warning,frame-address,)
> --8<---------------cut here---------------end--------------->8---
>
> But make still fails with it. :-(
---
?Makefile | 1 +
?1 file changed, 1 insertion(+)
diff --git a/Makefile b/Makefile
index 512e47a53e9a..e2a0d46820e4 100644
--- a/Makefile
+++ b/Makefile
@@ -400,6 +400,7 @@ KBUILD_CFLAGS???:= -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs \
? ???-Werror-implicit-function-declaration \
? ???-Wno-format-security \
? ???-std=gnu89
+KBUILD_CFLAGS += $(call cc-option,-fno-pie)
?
?KBUILD_AFLAGS_KERNEL :=
?KBUILD_CFLAGS_KERNEL :=
On 2016-10-24 09:43 +0200, Sebastian Andrzej Siewior wrote:
> On 2016-10-24 09:38:49 [+0200], Sven Joachim wrote:
>>
>> But make still fails with it. :-(
>
> try setting CONFIG_CC_STACKPROTECTOR_NONE=y and please let me know if
> the resulting kernel built with v3.2 gcc boots & works.
Sorry, I don't have gcc 3.2 around, and my gcc 3.3 environment produces
assembler errors in arch/x86/entry/entry_32.S. Maybe binutils 2.15 is
not recent enough anymore?
Anyway, with CONFIG_CC_STACKPROTECTOR=y it is necessary to add -fno-pie
in scripts/gcc-x86_64-has-stack-protector.sh as well, because that
script invokes the compiler without KBUILD_CFLAGS. That's probably not
a problem since -fstack-protector is newer than -fno-pie. The attached
patch works for me with Debian's gcc-6 package.
Cheers,
Sven
On Mon, 2016-10-24 at 19:32 +0200, Sven Joachim wrote:
(in the attachment)
> +KBUILD_CFLAGS += $(call cc-option,-fno-pie,)
trivia:
The trailing comma is not necessary though the Makefile
is a bit inconsistent about this.
$ git grep "KBUILD_CFLAGS.*call cc-option" Makefile
Makefile:KBUILD_CFLAGS += $(call cc-option,-fno-delete-null-pointer-checks,)
Makefile:KBUILD_CFLAGS += $(call cc-option,-ffunction-sections,)
Makefile:KBUILD_CFLAGS += $(call cc-option,-fdata-sections,)
Makefile:KBUILD_CFLAGS += $(call cc-option,--param=allow-store-data-races=0)
Makefile:KBUILD_CFLAGS += $(call cc-option,-fno-reorder-blocks,) \
Makefile:KBUILD_CFLAGS += $(call cc-option,-Wframe-larger-than=${CONFIG_FRAME_WARN})
Makefile:KBUILD_CFLAGS += $(call cc-option, -mno-global-merge,)
Makefile:KBUILD_CFLAGS += $(call cc-option, -fcatch-undefined-behavior)
Makefile:KBUILD_CFLAGS += $(call cc-option, -fno-var-tracking-assignments)
Makefile:KBUILD_CFLAGS += $(call cc-option, -gsplit-dwarf, -g)
Makefile:KBUILD_CFLAGS += $(call cc-option, -gdwarf-4,)
Makefile:KBUILD_CFLAGS += $(call cc-option, -femit-struct-debug-baseonly) \
Makefile:KBUILD_CFLAGS += $(call cc-option, -fno-inline-functions-called-once)
Makefile:KBUILD_CFLAGS += $(call cc-option,-Wdeclaration-after-statement,)
Makefile:KBUILD_CFLAGS += $(call cc-option,-fno-strict-overflow)
Makefile:KBUILD_CFLAGS += $(call cc-option,-fconserve-stack)
Makefile:KBUILD_CFLAGS += $(call cc-option,-Werror=implicit-int)
Makefile:KBUILD_CFLAGS += $(call cc-option,-Werror=strict-prototypes)
Makefile:KBUILD_CFLAGS += $(call cc-option,-Werror=date-time)
Makefile:KBUILD_CFLAGS += $(call cc-option,-Werror=incompatible-pointer-types)
On 2016-10-24 19:32:30 [+0200], Sven Joachim wrote:
> On 2016-10-24 09:43 +0200, Sebastian Andrzej Siewior wrote:
>
> > On 2016-10-24 09:38:49 [+0200], Sven Joachim wrote:
> >>
> >> But make still fails with it. :-(
> >
> > try setting CONFIG_CC_STACKPROTECTOR_NONE=y and please let me know if
> > the resulting kernel built with v3.2 gcc boots & works.
>
> Sorry, I don't have gcc 3.2 around, and my gcc 3.3 environment produces
> assembler errors in arch/x86/entry/entry_32.S. Maybe binutils 2.15 is
> not recent enough anymore?
so we use stone age gcc but take latest binutils and kernel? What about
lifting the limit of gcc 3.2? Is there any use case in 2016 to use gcc
3.2 on a recent kernel except whether it still compiles or not?
Sebastian
On 2016-10-25 09:30 +0200, Sebastian Andrzej Siewior wrote:
> On 2016-10-24 19:32:30 [+0200], Sven Joachim wrote:
>> On 2016-10-24 09:43 +0200, Sebastian Andrzej Siewior wrote:
>>
>> > On 2016-10-24 09:38:49 [+0200], Sven Joachim wrote:
>> >>
>> >> But make still fails with it. :-(
>> >
>> > try setting CONFIG_CC_STACKPROTECTOR_NONE=y and please let me know if
>> > the resulting kernel built with v3.2 gcc boots & works.
>>
>> Sorry, I don't have gcc 3.2 around, and my gcc 3.3 environment produces
>> assembler errors in arch/x86/entry/entry_32.S. Maybe binutils 2.15 is
>> not recent enough anymore?
I have done a few more tests, and I can confirm that binutils 2.17 is
the oldest version that works. Also, I have succeeded installing gcc
3.2 in a Debian 4.0 chroot now.
> so we use stone age gcc but take latest binutils and kernel? What about
> lifting the limit of gcc 3.2?
Would probably make sense, since gcc 3.2 cannot compile kernel/bounds.c,
at least not on x86.
,----
| CC kernel/bounds.s
| In file included from /tmp/linux/arch/x86/include/asm/bitops.h:512,
| from include/linux/bitops.h:22,
| from include/linux/kernel.h:10,
| from include/asm-generic/bug.h:13,
| from /tmp/linux/arch/x86/include/asm/bug.h:38,
| from include/linux/bug.h:4,
| from include/linux/page-flags.h:9,
| from kernel/bounds.c:9:
| /tmp/linux/arch/x86/include/asm/arch_hweight.h: In function `__arch_hweight32':
| /tmp/linux/arch/x86/include/asm/arch_hweight.h:29: syntax error before string constant
| make[1]: *** [kernel/bounds.s] Error 1
`----
Building with gcc 3.3 is apparently still possible, although it produces
tons of warnings and a modpost section mismatch. Still, requiring gcc
4.1 or newer would not be unreasonable, I think (still released a few
months earlier than binutils 2.17).
Cheers,
Sven
Hi Andrew,
On 2016-10-26 19:51:03 [+0200], Sven Joachim wrote:
> On 2016-10-25 09:30 +0200, Sebastian Andrzej Siewior wrote:
>
> > On 2016-10-24 19:32:30 [+0200], Sven Joachim wrote:
> >> On 2016-10-24 09:43 +0200, Sebastian Andrzej Siewior wrote:
> >>
> >> > On 2016-10-24 09:38:49 [+0200], Sven Joachim wrote:
> >> >>
> >> >> But make still fails with it. :-(
> >> >
> >> > try setting CONFIG_CC_STACKPROTECTOR_NONE=y and please let me know if
> >> > the resulting kernel built with v3.2 gcc boots & works.
> >>
> >> Sorry, I don't have gcc 3.2 around, and my gcc 3.3 environment produces
> >> assembler errors in arch/x86/entry/entry_32.S. Maybe binutils 2.15 is
> >> not recent enough anymore?
>
> I have done a few more tests, and I can confirm that binutils 2.17 is
> the oldest version that works. Also, I have succeeded installing gcc
> 3.2 in a Debian 4.0 chroot now.
>
> > so we use stone age gcc but take latest binutils and kernel? What about
> > lifting the limit of gcc 3.2?
>
> Would probably make sense, since gcc 3.2 cannot compile kernel/bounds.c,
> at least not on x86.
>
> ,----
> | CC kernel/bounds.s
> | In file included from /tmp/linux/arch/x86/include/asm/bitops.h:512,
> | from include/linux/bitops.h:22,
> | from include/linux/kernel.h:10,
> | from include/asm-generic/bug.h:13,
> | from /tmp/linux/arch/x86/include/asm/bug.h:38,
> | from include/linux/bug.h:4,
> | from include/linux/page-flags.h:9,
> | from kernel/bounds.c:9:
> | /tmp/linux/arch/x86/include/asm/arch_hweight.h: In function `__arch_hweight32':
> | /tmp/linux/arch/x86/include/asm/arch_hweight.h:29: syntax error before string constant
> | make[1]: *** [kernel/bounds.s] Error 1
> `----
>
> Building with gcc 3.3 is apparently still possible, although it produces
> tons of warnings and a modpost section mismatch. Still, requiring gcc
> 4.1 or newer would not be unreasonable, I think (still released a few
> months earlier than binutils 2.17).
I remember you had once a server box running some enterprise distro
which had an old gcc. Do you see any reason for not lifting the minimum
gcc version to v4.1 ?
> Cheers,
> Sven
Sebastian
On Fri, Oct 21, 2016 at 5:16 AM, Sebastian Andrzej Siewior
<[email protected]> wrote:
> Debian started to build the gcc with --enable-default-pie by default so the
> kernel build ends before it starts properly with:
> |kernel/bounds.c:1:0: error: code model kernel does not support PIC mode
>
> Is this okay or do we want some kind of check to see if -fno-PIE is supported?
> It is mentioned in the 4.4.7 gcc manpage is it is not *that* new :)
>
> Signed-off-by: Sebastian Andrzej Siewior <[email protected]>
> ---
> Makefile | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Makefile b/Makefile
> index bf6e44a421df..97296d66b586 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -398,7 +398,7 @@ KBUILD_CPPFLAGS := -D__KERNEL__
> KBUILD_CFLAGS := -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs \
> -fno-strict-aliasing -fno-common \
> -Werror-implicit-function-declaration \
> - -Wno-format-security \
> + -Wno-format-security -fno-PIE \
> -std=gnu89
>
> KBUILD_AFLAGS_KERNEL :=
> --
> 2.9.3
>
Hi,
I ran into this when I upgraded to Ubuntu 16.10. Ubuntu kernel team
has a patch posted for Ubuntu kernels. The patch talks about needing
have this work for other architectures. I applied part of the change
from the original Ubuntu patch -
https://patchwork.ozlabs.org/patch/616621/
Anyway, the following worked for me on x86-64 - both 4.8.4 and 4.9
diff --git a/Makefile b/Makefile
index 82a36ab..0a01ad1 100644
--- a/Makefile
+++ b/Makefile
@@ -651,6 +651,11 @@ ifneq ($(CONFIG_FRAME_WARN),0)
KBUILD_CFLAGS += $(call cc-option,-Wframe-larger-than=${CONFIG_FRAME_WARN})
endif
+# force no-pie for distro compilers that enable pie by default
+KBUILD_CFLAGS += $(call cc-option, -fno-pie)
+KBUILD_CFLAGS += $(call cc-option, -no-pie)
+KBUILD_AFLAGS += $(call cc-option, -fno-pie)
+
# This selects the stack protector compiler flag. Testing it is delayed
# until after .config has been reprocessed, in the prepare-compiler-check
# target.
thanks,
-- Shuah
On 2016-10-27 11:09:06 [-0600], Shuah Khan wrote:
> diff --git a/Makefile b/Makefile
> index 82a36ab..0a01ad1 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -651,6 +651,11 @@ ifneq ($(CONFIG_FRAME_WARN),0)
> KBUILD_CFLAGS += $(call cc-option,-Wframe-larger-than=${CONFIG_FRAME_WARN})
> endif
>
> +# force no-pie for distro compilers that enable pie by default
> +KBUILD_CFLAGS += $(call cc-option, -fno-pie)
> +KBUILD_CFLAGS += $(call cc-option, -no-pie)
so why do we need -no-pie? What is different from -fno-pie
> +KBUILD_AFLAGS += $(call cc-option, -fno-pie)
Why do need to pass this to the assembler? Is this for the
fstack-protector?
>
> thanks,
> -- Shuah
Sebastian
On Thu, 27 Oct 2016 09:28:24 +0200 Sebastian Andrzej Siewior <[email protected]> wrote:
> > Building with gcc 3.3 is apparently still possible, although it produces
> > tons of warnings and a modpost section mismatch. Still, requiring gcc
> > 4.1 or newer would not be unreasonable, I think (still released a few
> > months earlier than binutils 2.17).
>
> I remember you had once a server box running some enterprise distro
> which had an old gcc. Do you see any reason for not lifting the minimum
> gcc version to v4.1 ?
Seems OK to me. I do have a gcc-3.4.5 for mips, sh and sparc64 sitting
around but I basically never use them and should update.
Hi Sven,
On Mon, Oct 24, 2016 at 07:32:30PM +0200, Sven Joachim wrote:
> The attached patch works for me with Debian's gcc-6 package.
I tried your patch when building 4.8.5 on an up-to-date Debian testing and
still got this:
AS arch/x86/entry/vdso/vdso32/note.o
arch/x86/entry/vdso/vdso32/note.S:1:0: sorry, unimplemented: -mfentry isn’t supported for 32-bit in combination with -fpic
Adding KBUILD_AFLAGS += $(call cc-option,-fno-pie,) helps.
(Maybe that should be as-option instead. Don't know. There are lots of
AFLAGS=$(call cc-option, ...) in the Makefiles, anyway.)
--
Tomáš Janoušek, a.k.a. Pivník, a.k.a. Liskni_si, http://work.lisk.in/
On 2016-10-29 12:10 +0200, Tomas Janousek wrote:
> On Mon, Oct 24, 2016 at 07:32:30PM +0200, Sven Joachim wrote:
>> The attached patch works for me with Debian's gcc-6 package.
>
> I tried your patch when building 4.8.5 on an up-to-date Debian testing and
> still got this:
>
> AS arch/x86/entry/vdso/vdso32/note.o
> arch/x86/entry/vdso/vdso32/note.S:1:0: sorry, unimplemented: -mfentry
> isn’t supported for 32-bit in combination with -fpic
I cannot reproduce that, FWIW. Also, arch/x86/entry/vdso/Makefile seems
to explicitly filter out -mfentry from the compiler flags, but maybe I
misunderstand something.
Could you please show the exact command that's failing with "make V=1"?
> Adding KBUILD_AFLAGS += $(call cc-option,-fno-pie,) helps.
> (Maybe that should be as-option instead. Don't know. There are lots of
> AFLAGS=$(call cc-option, ...) in the Makefiles, anyway.)
This is what Ubuntu is doing, so it works at least for them, I suppose.
Cheers,
Sven
On Sat, Oct 29, 2016 at 07:03:30PM +0200, Sven Joachim wrote:
> I cannot reproduce that, FWIW. Also, arch/x86/entry/vdso/Makefile seems
> to explicitly filter out -mfentry from the compiler flags, but maybe I
> misunderstand something.
Compiler flags, yes; assembler flags, no. Perhaps adding
KBUILD_AFLAGS_32 := $(filter-out -mfentry,$(KBUILD_AFLAGS_32))
to arch/x86/entry/vdso/Makefile would fix the build as well. I have honestly
no idea which solution is better. :-)
> Could you please show the exact command that's failing with "make V=1"?
gcc -Wp,-MD,arch/x86/entry/vdso/vdso32/.note.o.d -nostdinc -isystem /usr/lib/gcc/i686-linux-gnu/6/include -I./arch/x86/include -I./arch/x86/include/generated/uapi -I./arch/x86/include/generated -I./include -I./arch/x86/include/uapi -I./include/uapi -I./include/generated/uapi -include ./include/linux/kconfig.h -D__KERNEL__ -D__ASSEMBLY__ -DCONFIG_X86_X32_ABI -DCONFIG_AS_CFI=1 -DCONFIG_AS_CFI_SIGNAL_FRAME=1 -DCONFIG_AS_CFI_SECTIONS=1 -DCONFIG_AS_FXSAVEQ=1 -DCONFIG_AS_SSSE3=1 -DCONFIG_AS_CRC32=1 -DCONFIG_AS_AVX=1 -DCONFIG_AS_AVX2=1 -DCONFIG_AS_SHA1_NI=1 -DCONFIG_AS_SHA256_NI=1 -Wa,-gdwarf-2 -mfentry -DCC_USING_FENTRY -DCC_HAVE_ASM_GOTO -DBUILD_VDSO -m32 -c -o arch/x86/entry/vdso/vdso32/note.o arch/x86/entry/vdso/vdso32/note.S
Is this file being built with your .config?
--
Tomáš Janoušek, a.k.a. Pivník, a.k.a. Liskni_si, http://work.lisk.in/
On 2016-10-29 21:21 +0200, Tomas Janousek wrote:
> On Sat, Oct 29, 2016 at 07:03:30PM +0200, Sven Joachim wrote:
>> I cannot reproduce that, FWIW. Also, arch/x86/entry/vdso/Makefile seems
>> to explicitly filter out -mfentry from the compiler flags, but maybe I
>> misunderstand something.
>
> Compiler flags, yes; assembler flags, no. Perhaps adding
>
> KBUILD_AFLAGS_32 := $(filter-out -mfentry,$(KBUILD_AFLAGS_32))
>
> to arch/x86/entry/vdso/Makefile would fix the build as well. I have honestly
> no idea which solution is better. :-)
>
>> Could you please show the exact command that's failing with "make V=1"?
>
> gcc -Wp,-MD,arch/x86/entry/vdso/vdso32/.note.o.d -nostdinc -isystem
> /usr/lib/gcc/i686-linux-gnu/6/include -I./arch/x86/include
> -I./arch/x86/include/generated/uapi -I./arch/x86/include/generated
> -I./include -I./arch/x86/include/uapi -I./include/uapi
> -I./include/generated/uapi -include ./include/linux/kconfig.h
> -D__KERNEL__ -D__ASSEMBLY__ -DCONFIG_X86_X32_ABI -DCONFIG_AS_CFI=1
> -DCONFIG_AS_CFI_SIGNAL_FRAME=1 -DCONFIG_AS_CFI_SECTIONS=1
> -DCONFIG_AS_FXSAVEQ=1 -DCONFIG_AS_SSSE3=1 -DCONFIG_AS_CRC32=1
> -DCONFIG_AS_AVX=1 -DCONFIG_AS_AVX2=1 -DCONFIG_AS_SHA1_NI=1
> -DCONFIG_AS_SHA256_NI=1 -Wa,-gdwarf-2 -mfentry -DCC_USING_FENTRY
> -DCC_HAVE_ASM_GOTO -DBUILD_VDSO -m32 -c -o
> arch/x86/entry/vdso/vdso32/note.o arch/x86/entry/vdso/vdso32/note.S
>
> Is this file being built with your .config?
Yes, and "-mfentry -DCC_USING_FENTRY" is missing from the gcc
commandline there. And not only there, although I have
CONFIG_FUNCTION_TRACER=y and CONFIG_HAVE_FENTRY=y, which should cause it
to be added to KBUILD_CFLAGS and KBUILD_AFLAGS.
I don't understand that, but it's late in the evening here.
Cheers,
Sven