gcc 4.9 build warnings (was: Re: next build: 2674 warnings 1 failures (next/next-20141022))

gcc 4.9 build warnings (was: Re: next build: 2674 warnings 1 failures (next/next-20141022))

[Russell King - ARM Linux]

On Tue, Oct 21, 2014 at 10:44:12PM -0700, Olof's autobuilder wrote:
> drivers/scsi/aic7xxx/aic7xxx_core.c:48:37: fatal error: dev/aic7xxx/aic7xxx_osm.h: No such file or directory
> drivers/scsi/aic7xxx/aic7xxx_93cx6.c:72:37: fatal error: dev/aic7xxx/aic7xxx_osm.h: No such file or directory
> drivers/scsi/aic7xxx/aic7xxx_pci.c:50:37: fatal error: dev/aic7xxx/aic7xxx_osm.h: No such file or directory
> drivers/scsi/aic7xxx/aic79xx_core.c:48:37: fatal error: dev/aic7xxx/aic79xx_osm.h: No such file or directory
> drivers/scsi/aic7xxx/aic79xx_pci.c:48:37: fatal error: dev/aic7xxx/aic79xx_osm.h: No such file or directory

I have a patch for the aic7xxx stuff to fix it for split builds, but
whenever I've talked to jejb about it, the response is always negative,
blaming my build environment as the cause of it because... apparently,
no one else sees problems.  Maybe it's time to gang up on jejb and
convince him otherwise?

>       3 arch/arm/common/dmabounce.c:318:2: warning: format '%zx' expects argument of type 'size_t', but argument 7 has type 'unsigned int' [-Wformat=]
>       3 arch/arm/common/dmabounce.c:369:2: warning: format '%zx' expects argument of type 'size_t', but argument 6 has type 'unsigned int' [-Wformat=]
>       3 arch/arm/common/dmabounce.c:409:2: warning: format '%zx' expects argument of type 'size_t', but argument 6 has type 'unsigned int' [-Wformat=]

I really can't fathom these warnings.  From what I can tell, in userspace,
size_t is typedef'd from the __SIZE_TYPE__ preprocessor definition, which
is provided by the compiler.  As Olof has already found out, with his gcc
4.9, __SIZE_TYPE__ is 'unsigned int'.

What I see in my latest compiler's provided stddef.h (from ubuntu 14.04.1's
gcc 4.8) is:

typedef __SIZE_TYPE__ size_t;

and sure enough:

$ echo '#include <stddef.h>' | gcc -E -xc -o - -

gives:

typedef unsigned int size_t;

In the kernel we have for ARM:

include/uapi/asm-generic/posix-types.h:typedef unsigned int    __kernel_size_t;
include/linux/types.h:typedef __kernel_size_t         size_t;

So, size_t is typedef'd as "unsigned int" - and indeed, the compiler thinks
that size_t is "unsigned int".  But it doesn't seem to like the use of the
'z' flag in the printf format string with size_t.

Any ideas what's going on here?  Does gcc 4.9 stddef.h define size_t
differently?

-- 
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.

gcc 4.9 build warnings (was: Re: next build: 2674 warnings 1 failures (next/next-20141022))

[Arnd Bergmann]

On Wednesday 22 October 2014 23:38:45 Russell King - ARM Linux wrote:
> On Tue, Oct 21, 2014 at 10:44:12PM -0700, Olof's autobuilder wrote:
> > drivers/scsi/aic7xxx/aic7xxx_core.c:48:37: fatal error: dev/aic7xxx/aic7xxx_osm.h: No such file or directory
> > drivers/scsi/aic7xxx/aic7xxx_93cx6.c:72:37: fatal error: dev/aic7xxx/aic7xxx_osm.h: No such file or directory
> > drivers/scsi/aic7xxx/aic7xxx_pci.c:50:37: fatal error: dev/aic7xxx/aic7xxx_osm.h: No such file or directory
> > drivers/scsi/aic7xxx/aic79xx_core.c:48:37: fatal error: dev/aic7xxx/aic79xx_osm.h: No such file or directory
> > drivers/scsi/aic7xxx/aic79xx_pci.c:48:37: fatal error: dev/aic7xxx/aic79xx_osm.h: No such file or directory
> 
> I have a patch for the aic7xxx stuff to fix it for split builds, but
> whenever I've talked to jejb about it, the response is always negative,
> blaming my build environment as the cause of it because... apparently,
> no one else sees problems.  Maybe it's time to gang up on jejb and
> convince him otherwise?

I think the problem here is

#ifdef __linux__
#include "aic7xxx_osm.h"
#include "aic7xxx_inline.h"
#include "aic7xxx_93cx6.h"
#else
#include <dev/aic7xxx/aic7xxx_osm.h>
#include <dev/aic7xxx/aic7xxx_inline.h>
#include <dev/aic7xxx/aic7xxx_93cx6.h>
#endif

so it should work as long as __linux__ is set. I remember having discussed similar
issues in the past, but don't remember the exact outcome. I would have expected
normal compilers to set __linux__, but we also have hacks in various places
to work around toolchains that don't

$ git grep __linux__
Makefile:CHECKFLAGS     := -D__linux__ -Dlinux -D__STDC__ -Dunix -D__unix__ \
arch/arc/Makefile:cflags-y      += -mA7 -fno-common -pipe -fno-builtin -D__linux__
arch/avr32/Makefile:KBUILD_CFLAGS       += -pipe -fno-builtin -mno-pic -D__linux__
arch/hexagon/Makefile:KBUILD_CFLAGS += -ffixed-$(TIR_NAME) -DTHREADINFO_REG=$(TIR_NAME) -D__linux__
arch/mips/include/uapi/asm/sgidefs.h:#ifndef __linux__
arch/openrisc/Makefile:KBUILD_CFLAGS    += -pipe -ffixed-r10 -D__linux__
arch/score/Makefile:    -D__linux__ -ffunction-sections -ffreestanding
arch/xtensa/Makefile:KBUILD_CFLAGS += -ffreestanding -D__linux__
drivers/gpu/drm/radeon/radeon_cp.c:#ifdef __linux__
drivers/gpu/drm/radeon/radeon_cp.c:#ifdef __linux__
drivers/scsi/aic7xxx/aic7770.c:#ifdef __linux__
drivers/scsi/aic7xxx/aic79xx.h:#ifndef __linux__
drivers/scsi/aic7xxx/aic79xx.h:#ifndef __linux__
drivers/scsi/aic7xxx/aic79xx_core.c:#ifdef __linux__
drivers/scsi/aic7xxx/aic79xx_core.c:#ifndef __linux__
drivers/scsi/aic7xxx/aic79xx_core.c:#ifndef __linux__
drivers/scsi/aic7xxx/aic79xx_core.c:#ifndef __linux__
drivers/scsi/aic7xxx/aic79xx_core.c:#ifndef __linux__
drivers/scsi/aic7xxx/aic79xx_core.c:#ifndef __linux__
drivers/scsi/aic7xxx/aic79xx_pci.c:#ifdef __linux__
drivers/scsi/aic7xxx/aic7xxx.h:#ifndef __linux__
drivers/scsi/aic7xxx/aic7xxx.h:#ifndef __linux__
drivers/scsi/aic7xxx/aic7xxx_93cx6.c:#ifdef __linux__
drivers/scsi/aic7xxx/aic7xxx_core.c:#ifdef __linux__
drivers/scsi/aic7xxx/aic7xxx_core.c:#ifndef __linux__
drivers/scsi/aic7xxx/aic7xxx_core.c:#ifndef __linux__
drivers/scsi/aic7xxx/aic7xxx_core.c:#ifndef __linux__
drivers/scsi/aic7xxx/aic7xxx_core.c:#ifndef __linux__
drivers/scsi/aic7xxx/aic7xxx_core.c:#ifndef __linux__
drivers/scsi/aic7xxx/aic7xxx_pci.c:#ifdef __linux__
drivers/scsi/aic7xxx/aicasm/aicasm.h:#ifdef __linux__
drivers/scsi/aic7xxx/aicasm/aicasm_gram.y:#ifdef __linux__
drivers/scsi/aic7xxx/aicasm/aicasm_macro_gram.y:#ifdef __linux__
drivers/scsi/aic7xxx/aicasm/aicasm_macro_scan.l:#ifdef __linux__
drivers/scsi/aic7xxx/aicasm/aicasm_scan.l:#ifdef __linux__
drivers/scsi/aic7xxx/aicasm/aicasm_symbol.c:#ifdef __linux__
drivers/scsi/aic7xxx/aicasm/aicasm_symbol.h:#ifdef __linux__
drivers/scsi/dpt/osd_defs.h:#if (defined(__linux__))
fs/ext4/ext4.h:#if defined(__KERNEL__) || defined(__linux__)
fs/ext4/ext4.h:#endif /* defined(__KERNEL__) || defined(__linux__) */
include/acpi/platform/acenv.h:#if defined(_LINUX) || defined(__linux__)
include/acpi/platform/acenvex.h:#if defined(_LINUX) || defined(__linux__)
include/linux/coda.h:#if defined(__linux__)
include/uapi/drm/drm.h:#if defined(__KERNEL__) || defined(__linux__)
include/uapi/linux/coda.h:#if defined(__linux__)

So five parts of the kernel check for __linux__, all of them are shared
with another OS, or at least used to be: drm, coda, ext4, acpi and aic7xxx.
The check is to determine whether we are building for Linux or not.
Some of them check for __KERNEL__ or __linux__, and we know that __KERNEL__
is always set when building the Linux kernel, and __linux__ is always set
when building Linux user space.

Some architectures evidently have workarounds to define __linux__ even
when building with other compilers.

See also https://bugs.launchpad.net/linaro-android/+bug/868550

> So, size_t is typedef'd as "unsigned int" - and indeed, the compiler thinks
> that size_t is "unsigned int".  But it doesn't seem to like the use of the
> 'z' flag in the printf format string with size_t.
> 
> Any ideas what's going on here?  Does gcc 4.9 stddef.h define size_t
> differently?

This may be a related issue to the first one. Maybe the linux toolchain uses
a different type from the generic toolchain. 

	Arnd

gcc 4.9 build warnings (was: Re: next build: 2674 warnings 1 failures (next/next-20141022))

[Russell King - ARM Linux]

On Thu, Oct 23, 2014 at 03:57:44PM +0200, Arnd Bergmann wrote:
> On Wednesday 22 October 2014 23:38:45 Russell King - ARM Linux wrote:
> > So, size_t is typedef'd as "unsigned int" - and indeed, the compiler thinks
> > that size_t is "unsigned int".  But it doesn't seem to like the use of the
> > 'z' flag in the printf format string with size_t.
> > 
> > Any ideas what's going on here?  Does gcc 4.9 stddef.h define size_t
> > differently?
> 
> This may be a related issue to the first one. Maybe the linux toolchain uses
> a different type from the generic toolchain. 

Please re-read.

Olof's 4.9 toolchain is the one which spat out these errors.

Olof's 4.9 toolchain defines __SIZE_TYPE__ to "unsigned int".  I asked
Olof to verify this via:

$ echo __SIZE_TYPE__ | arm-linux-gcc -E -o - -xc -

which Olof said produces "unsigned int".

Userspace typedefs size_t to __SIZE_TYPE__ which is "unsigned int".  Ergo,
in userspace, size_t is typedef'd from "unsigned int".

The kernel typedefs __kernel_size_t to "unsigned int", which is then
used to typedef the kernel size_t to __kernel_size_t.  Ergo, size_t in
the kernel is "unsigned int".

In the kernel, passing a variable with type size_t to a format with
"%zu", results in Olof's 4.9 toolchain complaining that the format
takes a size_t type, but GCC claims the variable passed was of type
"unsigned int" not "size_t".

Why?

-- 
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.

gcc 4.9 build warnings (was: Re: next build: 2674 warnings 1 failures (next/next-20141022))

[Arnd Bergmann]

On Thursday 23 October 2014 15:14:15 Russell King - ARM Linux wrote:
> On Thu, Oct 23, 2014 at 03:57:44PM +0200, Arnd Bergmann wrote:
> > On Wednesday 22 October 2014 23:38:45 Russell King - ARM Linux wrote:
> > > So, size_t is typedef'd as "unsigned int" - and indeed, the compiler thinks
> > > that size_t is "unsigned int".  But it doesn't seem to like the use of the
> > > 'z' flag in the printf format string with size_t.
> > > 
> > > Any ideas what's going on here?  Does gcc 4.9 stddef.h define size_t
> > > differently?
> > 
> > This may be a related issue to the first one. Maybe the linux toolchain uses
> > a different type from the generic toolchain. 
> 
> Please re-read.
> 
> Olof's 4.9 toolchain is the one which spat out these errors.
> 
> Olof's 4.9 toolchain defines __SIZE_TYPE__ to "unsigned int".  I asked
> Olof to verify this via:
> 
> $ echo __SIZE_TYPE__ | arm-linux-gcc -E -o - -xc -
> 
> which Olof said produces "unsigned int".
> 
> Userspace typedefs size_t to __SIZE_TYPE__ which is "unsigned int".  Ergo,
> in userspace, size_t is typedef'd from "unsigned int".
> 
> The kernel typedefs __kernel_size_t to "unsigned int", which is then
> used to typedef the kernel size_t to __kernel_size_t.  Ergo, size_t in
> the kernel is "unsigned int".
> 
> In the kernel, passing a variable with type size_t to a format with
> "%zu", results in Olof's 4.9 toolchain complaining that the format
> takes a size_t type, but GCC claims the variable passed was of type
> "unsigned int" not "size_t".

I was thinking of the case where gcc's internal code for printf format
checking doesn't match the definition of size_t. It's possible that this
is different from the type that is defined in stddef.h.

FWIW, the stddef.h that comes with my gcc-4.9 contains

#define __SIZE_TYPE__ long unsigned int

but the command

$ echo __SIZE_TYPE__ | arm-linux-gcc -E -o - -xc -

also returns "unsigned int" when running through the compiler that
comes with this header.

I haven't found the code in gcc that performs the type check for
printf, but I've found a comment about that code intentionally
resolving the type (printing 'unsigned int') when the typedef
does not match the expected type.

	Arnd

gcc 4.9 build warnings (was: Re: next build: 2674 warnings 1 failures (next/next-20141022))

[Russell King - ARM Linux]

On Thu, Oct 23, 2014 at 05:33:52PM +0200, Arnd Bergmann wrote:
> I was thinking of the case where gcc's internal code for printf format
> checking doesn't match the definition of size_t. It's possible that this
> is different from the type that is defined in stddef.h.
> 
> FWIW, the stddef.h that comes with my gcc-4.9 contains
> 
> #define __SIZE_TYPE__ long unsigned int
> 
> but the command
> 
> $ echo __SIZE_TYPE__ | arm-linux-gcc -E -o - -xc -
> 
> also returns "unsigned int" when running through the compiler that
> comes with this header.

Right, because the command version of __SIZE_TYPE__ is picking up the
value which gcc itself defines.  The #define in stddef.h is only used
if the compiler doesn't already define __SIZE_TYPE__ (as it's surrounded
with #ifndef __SIZE_TYPE__.)

> I haven't found the code in gcc that performs the type check for
> printf, but I've found a comment about that code intentionally
> resolving the type (printing 'unsigned int') when the typedef
> does not match the expected type.

If I had a copy of the GCC 4.9 source locally, I'd dig into it too and
try to work out what's going on.  My gut feeling is that it's a bug in
GCC rather than something which the kernel is doing wrong.

-- 
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.

gcc 4.9 build warnings (was: Re: next build: 2674 warnings 1 failures (next/next-20141022))

[Arnd Bergmann]

On Thursday 23 October 2014 17:12:20 Russell King - ARM Linux wrote:
> 
> > I haven't found the code in gcc that performs the type check for
> > printf, but I've found a comment about that code intentionally
> > resolving the type (printing 'unsigned int') when the typedef
> > does not match the expected type.
> 
> If I had a copy of the GCC 4.9 source locally, I'd dig into it too and
> try to work out what's going on.  My gut feeling is that it's a bug in
> GCC rather than something which the kernel is doing wrong.
> 

I suspect it has something to do with the way that Olof's gcc is built,
since it doesn't happen for me using the same kernel source and gcc-4.9.1
or 4.10-prerelease.

The fact that it doesn't define __linux__ means that it must be configured
in some other way than what I do or what I get from the distros.

	Arnd

gcc 4.9 build warnings (was: Re: next build: 2674 warnings 1 failures (next/next-20141022))

[Olof Johansson]

On Thu, Oct 23, 2014 at 1:31 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Thursday 23 October 2014 17:12:20 Russell King - ARM Linux wrote:
>>
>> > I haven't found the code in gcc that performs the type check for
>> > printf, but I've found a comment about that code intentionally
>> > resolving the type (printing 'unsigned int') when the typedef
>> > does not match the expected type.
>>
>> If I had a copy of the GCC 4.9 source locally, I'd dig into it too and
>> try to work out what's going on.  My gut feeling is that it's a bug in
>> GCC rather than something which the kernel is doing wrong.
>>
>
> I suspect it has something to do with the way that Olof's gcc is built,
> since it doesn't happen for me using the same kernel source and gcc-4.9.1
> or 4.10-prerelease.

Mine is a 4.9.1 built with segher's buildall scripts.

-Olof

gcc 4.9 build warnings (was: Re: next build: 2674 warnings 1 failures (next/next-20141022))

[Ard Biesheuvel]

On 23 October 2014 22:31, Arnd Bergmann <arnd@arndb.de> wrote:
> On Thursday 23 October 2014 17:12:20 Russell King - ARM Linux wrote:
>>
>> > I haven't found the code in gcc that performs the type check for
>> > printf, but I've found a comment about that code intentionally
>> > resolving the type (printing 'unsigned int') when the typedef
>> > does not match the expected type.
>>
>> If I had a copy of the GCC 4.9 source locally, I'd dig into it too and
>> try to work out what's going on.  My gut feeling is that it's a bug in
>> GCC rather than something which the kernel is doing wrong.
>>
>
> I suspect it has something to do with the way that Olof's gcc is built,
> since it doesn't happen for me using the same kernel source and gcc-4.9.1
> or 4.10-prerelease.
>
> The fact that it doesn't define __linux__ means that it must be configured
> in some other way than what I do or what I get from the distros.
>

I found a similar issue a while ago regarding uint32_t: on the bare
metal version of ARM gcc, it is typedef'ed as unsigned long, whereas
on the linux/glibc version, it is typedef'ed as unsigned int.

Patch here:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=09096f6a0ee2f2a26f3f11cf466fab0364405a23

We could add a '#define __SIZE_TYPE__ unsigned int' there as well, I suppose.

-- 
Ard.

gcc 4.9 build warnings (was: Re: next build: 2674 warnings 1 failures (next/next-20141022))

[Russell King - ARM Linux]

On Thu, Oct 23, 2014 at 10:31:07PM +0200, Arnd Bergmann wrote:
> On Thursday 23 October 2014 17:12:20 Russell King - ARM Linux wrote:
> > 
> > > I haven't found the code in gcc that performs the type check for
> > > printf, but I've found a comment about that code intentionally
> > > resolving the type (printing 'unsigned int') when the typedef
> > > does not match the expected type.
> > 
> > If I had a copy of the GCC 4.9 source locally, I'd dig into it too and
> > try to work out what's going on.  My gut feeling is that it's a bug in
> > GCC rather than something which the kernel is doing wrong.
> > 
> 
> I suspect it has something to do with the way that Olof's gcc is built,
> since it doesn't happen for me using the same kernel source and gcc-4.9.1
> or 4.10-prerelease.
> 
> The fact that it doesn't define __linux__ means that it must be configured
> in some other way than what I do or what I get from the distros.

Hmm, which may mean that it does expect "unsigned long" for size_t.

Olof, please can you try this fragment:

typedef __SIZE_TYPE__ gcc_size_t;
#include <stdio.h>
int main() { size_t size = 1; printf("%zu\n", size); return 0; }

with "arm-linux-gcc -E -o - test.c | grep size_t" and check what the
actual typedefs passed to the compiler proper are?  Thanks.

-- 
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.

gcc 4.9 build warnings (was: Re: next build: 2674 warnings 1 failures (next/next-20141022))

[Arnd Bergmann]

On Thursday 23 October 2014 13:33:13 Olof Johansson wrote:
> On Thu, Oct 23, 2014 at 1:31 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Thursday 23 October 2014 17:12:20 Russell King - ARM Linux wrote:
> >>
> >> > I haven't found the code in gcc that performs the type check for
> >> > printf, but I've found a comment about that code intentionally
> >> > resolving the type (printing 'unsigned int') when the typedef
> >> > does not match the expected type.
> >>
> >> If I had a copy of the GCC 4.9 source locally, I'd dig into it too and
> >> try to work out what's going on.  My gut feeling is that it's a bug in
> >> GCC rather than something which the kernel is doing wrong.
> >>
> >
> > I suspect it has something to do with the way that Olof's gcc is built,
> > since it doesn't happen for me using the same kernel source and gcc-4.9.1
> > or 4.10-prerelease.
> 
> Mine is a 4.9.1 built with segher's buildall scripts.
> 

Ok, that also explains the problems with the missing __linux__ macro, given
Ard's reply about bare-metal gcc.

I think we have two choices here:

a) change the buildall script so it actually builds a compiler that behaves
   in the way we expect for the kernel (__SIZE_TYPE__ and __linux__ at least,
   possibly others)

b) change the kernel to work with the way the bare-metal compiler is built,
   adding -D__linux__ in the ARM Makefile and applying Ard's workaround for
   __SIZE_TYPE__/__INT32_TYPE__/__UINT32_TYPE__/__UINTPTR_TYPE__.

Both options are a little hacky and I don't really like them, but I think
it makes sense to do one of them.

	Arnd

gcc 4.9 build warnings (was: Re: next build: 2674 warnings 1 failures (next/next-20141022))

[Arnd Bergmann]

On Friday 24 October 2014 11:13:27 Arnd Bergmann wrote:
> On Thursday 23 October 2014 13:33:13 Olof Johansson wrote:
> > On Thu, Oct 23, 2014 at 1:31 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> > > On Thursday 23 October 2014 17:12:20 Russell King - ARM Linux wrote:
> > >>
> > >> > I haven't found the code in gcc that performs the type check for
> > >> > printf, but I've found a comment about that code intentionally
> > >> > resolving the type (printing 'unsigned int') when the typedef
> > >> > does not match the expected type.
> > >>
> > >> If I had a copy of the GCC 4.9 source locally, I'd dig into it too and
> > >> try to work out what's going on.  My gut feeling is that it's a bug in
> > >> GCC rather than something which the kernel is doing wrong.
> > >>
> > >
> > > I suspect it has something to do with the way that Olof's gcc is built,
> > > since it doesn't happen for me using the same kernel source and gcc-4.9.1
> > > or 4.10-prerelease.
> > 
> > Mine is a 4.9.1 built with segher's buildall scripts.
> > 
> 
> Ok, that also explains the problems with the missing __linux__ macro, given
> Ard's reply about bare-metal gcc.
> 
> I think we have two choices here:
> 
> a) change the buildall script so it actually builds a compiler that behaves
>    in the way we expect for the kernel (__SIZE_TYPE__ and __linux__ at least,
>    possibly others)
> 
> b) change the kernel to work with the way the bare-metal compiler is built,
>    adding -D__linux__ in the ARM Makefile and applying Ard's workaround for
>    __SIZE_TYPE__/__INT32_TYPE__/__UINT32_TYPE__/__UINTPTR_TYPE__.
> 
> Both options are a little hacky and I don't really like them, but I think
> it makes sense to do one of them.

I now realized that Ard's fix for __INT32_TYPE__/__UINT32_TYPE__/__UINTPTR_TYPE__
was actually merged into the kernel but we are just missing the respective
__SIZE_TYPE__ change. I guess we should probably continue down that path then.

I've pushed the patch below to the to-build branch of arm-soc, so we should
see the output of Olof's build bot soon. If that works and everybody thinks
this is the right approach, I can add it to Russell's patch tracker.

I'm still undecided about the __linux__ macro, the alternative would be to
change the aic7xxx.h/coda.h/radeon_cp.c files to test for __KERNEL__ as well,
like we do in some other drivers.

	Arnd

commit 06c07738af3c409d89df5f9d370a52850faf260a
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Fri Oct 24 11:28:10 2014 +0200

    [EXPERIMENTAL] try to get Linux to build with bare-metal toolchain
    
    Toolchains built for bare-metal ARM targets rather than libc based
    targets do not set the __linux__ macro, and some types are slightly
    different, which causes annoying build errors.
    
    We already have workarounds in the kernel for some of the types,
    and this adds another one for size_t, which was recently discovered
    to be missing.
    
    We also set __linux__ unconditionally in the top-level Makefile,
    which gets a few drivers to build.
    
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>

diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index 034a94904d69..6646c1170d44 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -40,6 +40,9 @@ ifeq ($(CONFIG_FRAME_POINTER),y)
 KBUILD_CFLAGS	+=-fno-omit-frame-pointer -mapcs -mno-sched-prolog
 endif
 
+# freestanding toolchains don't define __linux__
+KBUILD_CFLAGS	+= -D__linux__
+
 ifeq ($(CONFIG_CPU_BIG_ENDIAN),y)
 KBUILD_CPPFLAGS	+= -mbig-endian
 AS		+= -EB
diff --git a/arch/arm/include/asm/types.h b/arch/arm/include/asm/types.h
index a53cdb8f068c..baaa8739b0bf 100644
--- a/arch/arm/include/asm/types.h
+++ b/arch/arm/include/asm/types.h
@@ -16,7 +16,7 @@
  * types, so 'linux/types.h' and 'stdint.h' can be safely included from the same
  * source file (provided that -ffreestanding is used).
  *
- *                    int32_t         uint32_t               uintptr_t
+ *                    int32_t         uint32_t/size_t        uintptr_t
  * bare metal GCC     long            unsigned long          unsigned int
  * glibc GCC          int             unsigned int           unsigned int
  * kernel             int             unsigned int           unsigned long
@@ -29,7 +29,12 @@
 
 #ifdef __UINT32_TYPE__
 #undef __UINT32_TYPE__
-#define __UINT32_TYPE__	unsigned int
+#define __UINT32_TYPE__		unsigned int
+#endif
+
+#ifdef __SIZE_TYPE__
+#undef __SIZE_TYPE__
+#define __SIZE_TYPE__		unsigned int
 #endif
 
 #ifdef __UINTPTR_TYPE__

gcc 4.9 build warnings (was: Re: next build: 2674 warnings 1 failures (next/next-20141022))

[Russell King - ARM Linux]

On Fri, Oct 24, 2014 at 11:13:27AM +0200, Arnd Bergmann wrote:
> Ok, that also explains the problems with the missing __linux__ macro, given
> Ard's reply about bare-metal gcc.
> 
> I think we have two choices here:
> 
> a) change the buildall script so it actually builds a compiler that behaves
>    in the way we expect for the kernel (__SIZE_TYPE__ and __linux__ at least,
>    possibly others)
> 
> b) change the kernel to work with the way the bare-metal compiler is built,
>    adding -D__linux__ in the ARM Makefile and applying Ard's workaround for
>    __SIZE_TYPE__/__INT32_TYPE__/__UINT32_TYPE__/__UINTPTR_TYPE__.
> 
> Both options are a little hacky and I don't really like them, but I think
> it makes sense to do one of them.

Well, (a) is probably the right answer.  EABI had (or still has) the
idea that enums can be a dynamic size, and this was taken out of the
Linux version of EABI.  What this means is that an enum used across an
interface between a compiler targetting Linux and one not targetting
Linux may not be compatible.

-- 
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.

gcc 4.9 build warnings (was: Re: next build: 2674 warnings 1 failures (next/next-20141022))

[Arnd Bergmann]

On Friday 24 October 2014 10:44:12 Russell King - ARM Linux wrote:
> On Fri, Oct 24, 2014 at 11:13:27AM +0200, Arnd Bergmann wrote:
> > Ok, that also explains the problems with the missing __linux__ macro, given
> > Ard's reply about bare-metal gcc.
> > 
> > I think we have two choices here:
> > 
> > a) change the buildall script so it actually builds a compiler that behaves
> >    in the way we expect for the kernel (__SIZE_TYPE__ and __linux__ at least,
> >    possibly others)
> > 
> > b) change the kernel to work with the way the bare-metal compiler is built,
> >    adding -D__linux__ in the ARM Makefile and applying Ard's workaround for
> >    __SIZE_TYPE__/__INT32_TYPE__/__UINT32_TYPE__/__UINTPTR_TYPE__.
> > 
> > Both options are a little hacky and I don't really like them, but I think
> > it makes sense to do one of them.
> 
> Well, (a) is probably the right answer.  EABI had (or still has) the
> idea that enums can be a dynamic size, and this was taken out of the
> Linux version of EABI.  What this means is that an enum used across an
> interface between a compiler targetting Linux and one not targetting
> Linux may not be compatible.

Ah, good point. Maybe we should also add #warning somewhere in an
ARM kernel file that warns about a compiler that doesn't set __linux__.

The alternative would be to add '-D__linux__ -fno-short-enums' to the
gcc flags, which for choice b, which should avoid this difference.

	Arnd

gcc 4.9 build warnings (was: Re: next build: 2674 warnings 1 failures (next/next-20141022))

[Segher Boessenkool]

On Fri, Oct 24, 2014 at 10:44:12AM +0100, Russell King - ARM Linux wrote:
> On Fri, Oct 24, 2014 at 11:13:27AM +0200, Arnd Bergmann wrote:
> > Ok, that also explains the problems with the missing __linux__ macro, given
> > Ard's reply about bare-metal gcc.
> > 
> > I think we have two choices here:
> > 
> > a) change the buildall script so it actually builds a compiler that behaves
> >    in the way we expect for the kernel (__SIZE_TYPE__ and __linux__ at least,
> >    possibly others)
> > 
> > b) change the kernel to work with the way the bare-metal compiler is built,
> >    adding -D__linux__ in the ARM Makefile and applying Ard's workaround for
> >    __SIZE_TYPE__/__INT32_TYPE__/__UINT32_TYPE__/__UINTPTR_TYPE__.
> > 
> > Both options are a little hacky and I don't really like them, but I think
> > it makes sense to do one of them.
> 
> Well, (a) is probably the right answer.  EABI had (or still has) the
> idea that enums can be a dynamic size, and this was taken out of the
> Linux version of EABI.  What this means is that an enum used across an
> interface between a compiler targetting Linux and one not targetting
> Linux may not be compatible.

Hi!  Happy to hear some people still find buildall useful.

The standard arm toolchains it builds are configured for arm-linux-eabi,
not "plain" eabi.  So what goes wrong?

Oh.  I changed that april this year; so just update your buildall.

[But of course it would be good if the kernel build would work with *any*
reasonable toolchain.  OTOH it seems that most arm toolchains aren't
reasonable.]


Segher

gcc 4.9 build warnings (was: Re: next build: 2674 warnings 1 failures (next/next-20141022))

[Russell King - ARM Linux]

On Fri, Oct 24, 2014 at 01:25:09PM -0500, Segher Boessenkool wrote:
> [But of course it would be good if the kernel build would work with *any*
> reasonable toolchain.  OTOH it seems that most arm toolchains aren't
> reasonable.]

It would be nice - we've passed enough flags for a long time to GCC to
try and ensure that, but GCC has a long history of changing stuff in
ways which break stuff.

It needs someone who has a foot in both camps to keep track of what's
happening in GCC, and what's needed to keep the kernel in sync.

As I tend to avoid toolchain upgrades as a rule of thumb, that person
isn't me. :)  I prefer to know where I stand with my toolchain, rather
than constantly being in the situation of having to question whether
every kernel oops is a result of a compiler bug.

-- 
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.

gcc 4.9 build warnings (was: Re: next build: 2674 warnings 1 failures (next/next-20141022))

[Olof Johansson]

On Thu, Oct 23, 2014 at 3:26 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Thu, Oct 23, 2014 at 10:31:07PM +0200, Arnd Bergmann wrote:
>> On Thursday 23 October 2014 17:12:20 Russell King - ARM Linux wrote:
>> >
>> > > I haven't found the code in gcc that performs the type check for
>> > > printf, but I've found a comment about that code intentionally
>> > > resolving the type (printing 'unsigned int') when the typedef
>> > > does not match the expected type.
>> >
>> > If I had a copy of the GCC 4.9 source locally, I'd dig into it too and
>> > try to work out what's going on.  My gut feeling is that it's a bug in
>> > GCC rather than something which the kernel is doing wrong.
>> >
>>
>> I suspect it has something to do with the way that Olof's gcc is built,
>> since it doesn't happen for me using the same kernel source and gcc-4.9.1
>> or 4.10-prerelease.
>>
>> The fact that it doesn't define __linux__ means that it must be configured
>> in some other way than what I do or what I get from the distros.
>
> Hmm, which may mean that it does expect "unsigned long" for size_t.
>
> Olof, please can you try this fragment:
>
> typedef __SIZE_TYPE__ gcc_size_t;
> #include <stdio.h>
> int main() { size_t size = 1; printf("%zu\n", size); return 0; }
>
> with "arm-linux-gcc -E -o - test.c | grep size_t" and check what the
> actual typedefs passed to the compiler proper are?  Thanks.


Since it's a baremetal compiler, there's no stdio.h. Anyway, taking
out the include line:

typedef unsigned int gcc_size_t;
int main() { size_t size = 1; printf("%zu\n", size); return 0; }


I guess I should just look at building a full compiler set instead of
this silliness. On the other hand, it's good to get it exposed I
suppose.


-Olof

gcc 4.9 build warnings (was: Re: next build: 2674 warnings 1 failures (next/next-20141022))

[Olof Johansson]

On Fri, Oct 24, 2014 at 11:25 AM, Segher Boessenkool
<segher@kernel.crashing.org> wrote:
> On Fri, Oct 24, 2014 at 10:44:12AM +0100, Russell King - ARM Linux wrote:
>> On Fri, Oct 24, 2014 at 11:13:27AM +0200, Arnd Bergmann wrote:
>> > Ok, that also explains the problems with the missing __linux__ macro, given
>> > Ard's reply about bare-metal gcc.
>> >
>> > I think we have two choices here:
>> >
>> > a) change the buildall script so it actually builds a compiler that behaves
>> >    in the way we expect for the kernel (__SIZE_TYPE__ and __linux__ at least,
>> >    possibly others)
>> >
>> > b) change the kernel to work with the way the bare-metal compiler is built,
>> >    adding -D__linux__ in the ARM Makefile and applying Ard's workaround for
>> >    __SIZE_TYPE__/__INT32_TYPE__/__UINT32_TYPE__/__UINTPTR_TYPE__.
>> >
>> > Both options are a little hacky and I don't really like them, but I think
>> > it makes sense to do one of them.
>>
>> Well, (a) is probably the right answer.  EABI had (or still has) the
>> idea that enums can be a dynamic size, and this was taken out of the
>> Linux version of EABI.  What this means is that an enum used across an
>> interface between a compiler targetting Linux and one not targetting
>> Linux may not be compatible.
>
> Hi!  Happy to hear some people still find buildall useful.
>
> The standard arm toolchains it builds are configured for arm-linux-eabi,
> not "plain" eabi.  So what goes wrong?
>
> Oh.  I changed that april this year; so just update your buildall.

Hm, my 4.9.1 was built in June, and I seem to have pulled down your
update by then (I did that in May).

> [But of course it would be good if the kernel build would work with *any*
> reasonable toolchain.  OTOH it seems that most arm toolchains aren't
> reasonable.]

Yeah, I agree with this but at some point I guess it just gets to be
_too_ crazy to try to do that.


-Olof

gcc 4.9 build warnings (was: Re: next build: 2674 warnings 1 failures (next/next-20141022))

[Russell King - ARM Linux]

On Fri, Oct 24, 2014 at 02:47:29PM -0700, Olof Johansson wrote:
> On Thu, Oct 23, 2014 at 3:26 PM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > On Thu, Oct 23, 2014 at 10:31:07PM +0200, Arnd Bergmann wrote:
> >> On Thursday 23 October 2014 17:12:20 Russell King - ARM Linux wrote:
> >> >
> >> > > I haven't found the code in gcc that performs the type check for
> >> > > printf, but I've found a comment about that code intentionally
> >> > > resolving the type (printing 'unsigned int') when the typedef
> >> > > does not match the expected type.
> >> >
> >> > If I had a copy of the GCC 4.9 source locally, I'd dig into it too and
> >> > try to work out what's going on.  My gut feeling is that it's a bug in
> >> > GCC rather than something which the kernel is doing wrong.
> >> >
> >>
> >> I suspect it has something to do with the way that Olof's gcc is built,
> >> since it doesn't happen for me using the same kernel source and gcc-4.9.1
> >> or 4.10-prerelease.
> >>
> >> The fact that it doesn't define __linux__ means that it must be configured
> >> in some other way than what I do or what I get from the distros.
> >
> > Hmm, which may mean that it does expect "unsigned long" for size_t.
> >
> > Olof, please can you try this fragment:
> >
> > typedef __SIZE_TYPE__ gcc_size_t;
> > #include <stdio.h>
> > int main() { size_t size = 1; printf("%zu\n", size); return 0; }
> >
> > with "arm-linux-gcc -E -o - test.c | grep size_t" and check what the
> > actual typedefs passed to the compiler proper are?  Thanks.
> 
> 
> Since it's a baremetal compiler, there's no stdio.h. Anyway, taking
> out the include line:
> 
> typedef unsigned int gcc_size_t;
> int main() { size_t size = 1; printf("%zu\n", size); return 0; }
> 
> 
> I guess I should just look at building a full compiler set instead of
> this silliness. On the other hand, it's good to get it exposed I
> suppose.

In which case, use #include <stddef.h> which should be provided by
the compiler.

-- 
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.

gcc 4.9 build warnings (was: Re: next build: 2674 warnings 1 failures (next/next-20141022))

[Olof Johansson]

On Fri, Oct 24, 2014 at 2:56 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Fri, Oct 24, 2014 at 02:47:29PM -0700, Olof Johansson wrote:
>> On Thu, Oct 23, 2014 at 3:26 PM, Russell King - ARM Linux
>> <linux@arm.linux.org.uk> wrote:
>> > On Thu, Oct 23, 2014 at 10:31:07PM +0200, Arnd Bergmann wrote:
>> >> On Thursday 23 October 2014 17:12:20 Russell King - ARM Linux wrote:
>> >> >
>> >> > > I haven't found the code in gcc that performs the type check for
>> >> > > printf, but I've found a comment about that code intentionally
>> >> > > resolving the type (printing 'unsigned int') when the typedef
>> >> > > does not match the expected type.
>> >> >
>> >> > If I had a copy of the GCC 4.9 source locally, I'd dig into it too and
>> >> > try to work out what's going on.  My gut feeling is that it's a bug in
>> >> > GCC rather than something which the kernel is doing wrong.
>> >> >
>> >>
>> >> I suspect it has something to do with the way that Olof's gcc is built,
>> >> since it doesn't happen for me using the same kernel source and gcc-4.9.1
>> >> or 4.10-prerelease.
>> >>
>> >> The fact that it doesn't define __linux__ means that it must be configured
>> >> in some other way than what I do or what I get from the distros.
>> >
>> > Hmm, which may mean that it does expect "unsigned long" for size_t.
>> >
>> > Olof, please can you try this fragment:
>> >
>> > typedef __SIZE_TYPE__ gcc_size_t;
>> > #include <stdio.h>
>> > int main() { size_t size = 1; printf("%zu\n", size); return 0; }
>> >
>> > with "arm-linux-gcc -E -o - test.c | grep size_t" and check what the
>> > actual typedefs passed to the compiler proper are?  Thanks.
>>
>>
>> Since it's a baremetal compiler, there's no stdio.h. Anyway, taking
>> out the include line:
>>
>> typedef unsigned int gcc_size_t;
>> int main() { size_t size = 1; printf("%zu\n", size); return 0; }
>>
>>
>> I guess I should just look at building a full compiler set instead of
>> this silliness. On the other hand, it's good to get it exposed I
>> suppose.
>
> In which case, use #include <stddef.h> which should be provided by
> the compiler.

Yes, of course. Changing stdio to stddef:

$ /usr/local/cross-4.9.1/bin/arm-linux-eabi-gcc -E -o - test.c | grep size_t
typedef unsigned int gcc_size_t;
typedef unsigned int size_t;
int main() { size_t size = 1; printf("%zu\n", size); return 0; }


-Olof

gcc 4.9 build warnings (was: Re: next build: 2674 warnings 1 failures (next/next-20141022))

[Arnd Bergmann]

On Friday 24 October 2014 13:25:09 Segher Boessenkool wrote:
> On Fri, Oct 24, 2014 at 10:44:12AM +0100, Russell King - ARM Linux wrote:
> > On Fri, Oct 24, 2014 at 11:13:27AM +0200, Arnd Bergmann wrote:
> > > Ok, that also explains the problems with the missing __linux__ macro, given
> > > Ard's reply about bare-metal gcc.
> > > 
> > > I think we have two choices here:
> > > 
> > > a) change the buildall script so it actually builds a compiler that behaves
> > >    in the way we expect for the kernel (__SIZE_TYPE__ and __linux__ at least,
> > >    possibly others)
> > > 
> > > b) change the kernel to work with the way the bare-metal compiler is built,
> > >    adding -D__linux__ in the ARM Makefile and applying Ard's workaround for
> > >    __SIZE_TYPE__/__INT32_TYPE__/__UINT32_TYPE__/__UINTPTR_TYPE__.
> > > 
> > > Both options are a little hacky and I don't really like them, but I think
> > > it makes sense to do one of them.
> > 
> > Well, (a) is probably the right answer.  EABI had (or still has) the
> > idea that enums can be a dynamic size, and this was taken out of the
> > Linux version of EABI.  What this means is that an enum used across an
> > interface between a compiler targetting Linux and one not targetting
> > Linux may not be compatible.
> 
> Hi!  Happy to hear some people still find buildall useful.
> 
> The standard arm toolchains it builds are configured for arm-linux-eabi,
> not "plain" eabi.  So what goes wrong?
> 
> Oh.  I changed that april this year; so just update your buildall.
> 
> [But of course it would be good if the kernel build would work with *any*
> reasonable toolchain.  OTOH it seems that most arm toolchains aren't
> reasonable.]
> 

I've decided to investigate it further. It seems that your change to
'arm-linux-eabi' did not have the intended effect. I got it to work with
this patch:

diff --git a/build b/build
index 10416a8..b2d38ec 100755
--- a/build
+++ b/build
@@ -36,7 +36,7 @@ case $ARCH in
 	*-eabi)		TARGET=$ARCH ;;
 	*-elf)		TARGET=$ARCH ;;
 
-	arm)		TARGET=arm-linux-eabi ;;
+	arm)		TARGET=arm-linux-gnueabi ;;
 	avr32)		TARGET=avr-linux ;;
 	blackfin)	TARGET=bfin-uclinux ;;
 	h8300)		TARGET=h8300-elf ;;


What happens in gcc apparently is that the configuration logic gets confused
and uses this entry in gcc/config.gcc:

arm*-*-eabi*)
        default_use_cxa_atexit=yes
        tm_file="dbxelf.h elfos.h arm/unknown-elf.h arm/elf.h arm/bpabi.h"
        tmake_file="${tmake_file} arm/t-arm arm/t-arm-elf"
        tm_file="$tm_file newlib-stdint.h"
        tmake_file="${tmake_file} arm/t-bpabi"
        use_gcc_stdint=wrap
        tm_file="${tm_file} arm/aout.h vxworks-dummy.h arm/arm.h"
        ;;

instead of this one:

arm*-*-linux-*)                 # ARM GNU/Linux with ELF
        tm_file="dbxelf.h elfos.h gnu-user.h linux.h linux-android.h glibc-stdint.h arm/elf.h arm/linux-gas.h arm/linux-elf.h"
        extra_options="${extra_options} linux-android.opt"
        tmake_file="${tmake_file} arm/t-arm arm/t-arm-elf arm/t-bpabi arm/t-linux-eabi"
        tm_file="$tm_file arm/bpabi.h arm/linux-eabi.h arm/aout.h vxworks-dummy.h arm/arm.h"
        # The EABI requires the use of __cxa_atexit.
        default_use_cxa_atexit=yes
        with_tls=${with_tls:-gnu}
        ;;

so among other things, we are missing linux.h and glibc-stdint.h.

	Arnd

gcc 4.9 build warnings (was: Re: next build: 2674 warnings 1 failures (next/next-20141022))

[Olof Johansson]

Hey, look at that:

http://arm-soc.lixom.net/buildlogs/misc/v3.18-rc2/

I've updated the toolchain now, so new builds should be using the proper one.

Thanks a lot for figuring this out. Segher, feel free to update your
scripts -- I've got a local edit for it here now. :)


-Olof

On Tue, Nov 11, 2014 at 1:32 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Friday 24 October 2014 13:25:09 Segher Boessenkool wrote:
>> On Fri, Oct 24, 2014 at 10:44:12AM +0100, Russell King - ARM Linux wrote:
>> > On Fri, Oct 24, 2014 at 11:13:27AM +0200, Arnd Bergmann wrote:
>> > > Ok, that also explains the problems with the missing __linux__ macro, given
>> > > Ard's reply about bare-metal gcc.
>> > >
>> > > I think we have two choices here:
>> > >
>> > > a) change the buildall script so it actually builds a compiler that behaves
>> > >    in the way we expect for the kernel (__SIZE_TYPE__ and __linux__ at least,
>> > >    possibly others)
>> > >
>> > > b) change the kernel to work with the way the bare-metal compiler is built,
>> > >    adding -D__linux__ in the ARM Makefile and applying Ard's workaround for
>> > >    __SIZE_TYPE__/__INT32_TYPE__/__UINT32_TYPE__/__UINTPTR_TYPE__.
>> > >
>> > > Both options are a little hacky and I don't really like them, but I think
>> > > it makes sense to do one of them.
>> >
>> > Well, (a) is probably the right answer.  EABI had (or still has) the
>> > idea that enums can be a dynamic size, and this was taken out of the
>> > Linux version of EABI.  What this means is that an enum used across an
>> > interface between a compiler targetting Linux and one not targetting
>> > Linux may not be compatible.
>>
>> Hi!  Happy to hear some people still find buildall useful.
>>
>> The standard arm toolchains it builds are configured for arm-linux-eabi,
>> not "plain" eabi.  So what goes wrong?
>>
>> Oh.  I changed that april this year; so just update your buildall.
>>
>> [But of course it would be good if the kernel build would work with *any*
>> reasonable toolchain.  OTOH it seems that most arm toolchains aren't
>> reasonable.]
>>
>
> I've decided to investigate it further. It seems that your change to
> 'arm-linux-eabi' did not have the intended effect. I got it to work with
> this patch:
>
> diff --git a/build b/build
> index 10416a8..b2d38ec 100755
> --- a/build
> +++ b/build
> @@ -36,7 +36,7 @@ case $ARCH in
>         *-eabi)         TARGET=$ARCH ;;
>         *-elf)          TARGET=$ARCH ;;
>
> -       arm)            TARGET=arm-linux-eabi ;;
> +       arm)            TARGET=arm-linux-gnueabi ;;
>         avr32)          TARGET=avr-linux ;;
>         blackfin)       TARGET=bfin-uclinux ;;
>         h8300)          TARGET=h8300-elf ;;
>
>
> What happens in gcc apparently is that the configuration logic gets confused
> and uses this entry in gcc/config.gcc:
>
> arm*-*-eabi*)
>         default_use_cxa_atexit=yes
>         tm_file="dbxelf.h elfos.h arm/unknown-elf.h arm/elf.h arm/bpabi.h"
>         tmake_file="${tmake_file} arm/t-arm arm/t-arm-elf"
>         tm_file="$tm_file newlib-stdint.h"
>         tmake_file="${tmake_file} arm/t-bpabi"
>         use_gcc_stdint=wrap
>         tm_file="${tm_file} arm/aout.h vxworks-dummy.h arm/arm.h"
>         ;;
>
> instead of this one:
>
> arm*-*-linux-*)                 # ARM GNU/Linux with ELF
>         tm_file="dbxelf.h elfos.h gnu-user.h linux.h linux-android.h glibc-stdint.h arm/elf.h arm/linux-gas.h arm/linux-elf.h"
>         extra_options="${extra_options} linux-android.opt"
>         tmake_file="${tmake_file} arm/t-arm arm/t-arm-elf arm/t-bpabi arm/t-linux-eabi"
>         tm_file="$tm_file arm/bpabi.h arm/linux-eabi.h arm/aout.h vxworks-dummy.h arm/arm.h"
>         # The EABI requires the use of __cxa_atexit.
>         default_use_cxa_atexit=yes
>         with_tls=${with_tls:-gnu}
>         ;;
>
> so among other things, we are missing linux.h and glibc-stdint.h.
>
>         Arnd

gcc 4.9 build warnings (was: Re: next build: 2674 warnings 1 failures (next/next-20141022))

[Russell King - ARM Linux]

On Tue, Nov 11, 2014 at 05:34:54PM -0800, Olof Johansson wrote:
> Hey, look at that:
> 
> http://arm-soc.lixom.net/buildlogs/misc/v3.18-rc2/
> 
> I've updated the toolchain now, so new builds should be using the proper one.
> 
> Thanks a lot for figuring this out. Segher, feel free to update your
> scripts -- I've got a local edit for it here now. :)

Great, thanks Olof and others for fixing this.  Now all we need is for
people to fix their warnings/errors in the latest -next build, some of
which have been hanging around for some time.  Like the irq_reg_readl()
error for the Marvell platforms...

-- 
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.

gcc 4.9 build warnings (was: Re: next build: 2674 warnings 1 failures (next/next-20141022))

[Segher Boessenkool]

On Tue, Nov 11, 2014 at 10:32:23PM +0100, Arnd Bergmann wrote:
> I've decided to investigate it further. It seems that your change to
> 'arm-linux-eabi' did not have the intended effect.

"It worked for me", i.e., it did build kernels.  I don't build arm terribly
often, does it show?

> I got it to work with this patch:

> -	arm)		TARGET=arm-linux-eabi ;;
> +	arm)		TARGET=arm-linux-gnueabi ;;

That looks right (and Olof says it works :-) ).  I'll apply the patch.

> What happens in gcc apparently is that the configuration logic gets confused
> and uses this entry in gcc/config.gcc:
> 
> arm*-*-eabi*)
>         default_use_cxa_atexit=yes
>         tm_file="dbxelf.h elfos.h arm/unknown-elf.h arm/elf.h arm/bpabi.h"
>         tmake_file="${tmake_file} arm/t-arm arm/t-arm-elf"
>         tm_file="$tm_file newlib-stdint.h"
>         tmake_file="${tmake_file} arm/t-bpabi"
>         use_gcc_stdint=wrap
>         tm_file="${tm_file} arm/aout.h vxworks-dummy.h arm/arm.h"
>         ;;
> 
> instead of this one:
> 
> arm*-*-linux-*)                 # ARM GNU/Linux with ELF

That one would match arm-unknown-linux-eabi (as it does
arm-unknown-linux-gnueabi), not arm-linux-eabi.  "triples" ;-)

arm-linux-eabi canonicalises to arm-linux-eabi;
arm-linux-gnueabi canonicalises to arm-unknown-linux-gnueabi.

>         tm_file="dbxelf.h elfos.h gnu-user.h linux.h linux-android.h glibc-stdint.h arm/elf.h arm/linux-gas.h arm/linux-elf.h"
>         extra_options="${extra_options} linux-android.opt"
>         tmake_file="${tmake_file} arm/t-arm arm/t-arm-elf arm/t-bpabi arm/t-linux-eabi"
>         tm_file="$tm_file arm/bpabi.h arm/linux-eabi.h arm/aout.h vxworks-dummy.h arm/arm.h"
>         # The EABI requires the use of __cxa_atexit.
>         default_use_cxa_atexit=yes
>         with_tls=${with_tls:-gnu}
>         ;;
> 
> so among other things, we are missing linux.h and glibc-stdint.h.

Right.  The kernel should not depend on anything about userland (i.e., the
linux.h header); but the stdint thing is needed to get the ABI you expect it
seems.

Great that you managed to figure out the mess,


Segher

gcc 4.9 build warnings (was: Re: next build: 2674 warnings 1 failures (next/next-20141022))

[Arnd Bergmann]

On Thursday 13 November 2014 08:19:50 Segher Boessenkool wrote:
> On Tue, Nov 11, 2014 at 10:32:23PM +0100, Arnd Bergmann wrote:
> > I've decided to investigate it further. It seems that your change to
> > 'arm-linux-eabi' did not have the intended effect.
> 
> "It worked for me", i.e., it did build kernels.  I don't build arm terribly
> often, does it show?

It builds most kernels, but produces extra warnings because some of the
types are different and a handful of drivers don't build if the __linux__
macro is not set. Any user ABI that depends on the size of an enum is
potentially broken.

> > What happens in gcc apparently is that the configuration logic gets confused
> > and uses this entry in gcc/config.gcc:
> > 
> > arm*-*-eabi*)
> >         default_use_cxa_atexit=yes
> >         tm_file="dbxelf.h elfos.h arm/unknown-elf.h arm/elf.h arm/bpabi.h"
> >         tmake_file="${tmake_file} arm/t-arm arm/t-arm-elf"
> >         tm_file="$tm_file newlib-stdint.h"
> >         tmake_file="${tmake_file} arm/t-bpabi"
> >         use_gcc_stdint=wrap
> >         tm_file="${tm_file} arm/aout.h vxworks-dummy.h arm/arm.h"
> >         ;;
> > 
> > instead of this one:
> > 
> > arm*-*-linux-*)                 # ARM GNU/Linux with ELF
> 
> That one would match arm-unknown-linux-eabi (as it does
> arm-unknown-linux-gnueabi), not arm-linux-eabi.  "triples" ;-)

Right, but config.sub thinks that is invalid.

> arm-linux-eabi canonicalises to arm-linux-eabi;
> arm-linux-gnueabi canonicalises to arm-unknown-linux-gnueabi.

Yes, that's what I found too.

	Arnd