ARM compile failure in Re: linux-next: Tree for Apr 4

ARM compile failure in Re: linux-next: Tree for Apr 4

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 1355 bytes --]

Hi!

> Please do not add any v4.18 destined stuff to your linux-next included
> trees until after v4.17-rc1 has been released.
> 
> Changes since 20180403:
> 
> The vfs tree still had its build failure for which I reverted a commit.
> 
> Non-merge commits (relative to Linus' tree): 8505
>  8493 files changed, 392779 insertions(+), 275941 deletions(-)
> 
> ----------------------------------------------------------------------------

When trying to build kernel for N900, I get:

  CC      lib/timerqueue.o
    CC      lib/vsprintf.o
    lib/string.c: In function 'strstr':
    lib/string.c:478:8: error: inlining failed in call to
    always_inline 'strlen': function not inlinable
    lib/string.c:903:5: error: called from here
    lib/string.c:478:8: error: inlining failed in call to
    always_inline 'strlen': function not inlinable
    lib/string.c:906:5: error: called from here
    lib/string.c:855:15: error: inlining failed in call to
    always_inline 'memcmp': function not inlinable
    ...
pavel@duo:/data/l/linux-next-n900$ git branch -l
* (detached from next-20180403)

I'm using

eval ` eldk-switch.sh -r 5.4 armv7a`

for cross-compilation.

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: ARM compile failure in Re: linux-next: Tree for Apr 4

[Tony Lindgren]

* Pavel Machek <pavel@ucw.cz> [180404 07:50]:
> Hi!
> 
> > Please do not add any v4.18 destined stuff to your linux-next included
> > trees until after v4.17-rc1 has been released.
> > 
> > Changes since 20180403:
> > 
> > The vfs tree still had its build failure for which I reverted a commit.
> > 
> > Non-merge commits (relative to Linus' tree): 8505
> >  8493 files changed, 392779 insertions(+), 275941 deletions(-)
> > 
> > ----------------------------------------------------------------------------
> 
> When trying to build kernel for N900, I get:
> 
>   CC      lib/timerqueue.o
>     CC      lib/vsprintf.o
>     lib/string.c: In function 'strstr':
>     lib/string.c:478:8: error: inlining failed in call to
>     always_inline 'strlen': function not inlinable
>     lib/string.c:903:5: error: called from here
>     lib/string.c:478:8: error: inlining failed in call to
>     always_inline 'strlen': function not inlinable
>     lib/string.c:906:5: error: called from here
>     lib/string.c:855:15: error: inlining failed in call to
>     always_inline 'memcmp': function not inlinable
>     ...
> pavel@duo:/data/l/linux-next-n900$ git branch -l
> * (detached from next-20180403)
> 
> I'm using
> 
> eval ` eldk-switch.sh -r 5.4 armv7a`
> 
> for cross-compilation.

Hmm I'm not seeing build issues with next-20180404, did this somehow
already get sorted out?

Regards,

Tony

Re: ARM compile failure in Re: linux-next: Tree for Apr 4

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 1952 bytes --]

Hi!

> > > Please do not add any v4.18 destined stuff to your linux-next included
> > > trees until after v4.17-rc1 has been released.
> > > 
> > > Changes since 20180403:
> > > 
> > > The vfs tree still had its build failure for which I reverted a commit.
> > > 
> > > Non-merge commits (relative to Linus' tree): 8505
> > >  8493 files changed, 392779 insertions(+), 275941 deletions(-)
> > > 
> > > ----------------------------------------------------------------------------
> > 
> > When trying to build kernel for N900, I get:
> > 
> >   CC      lib/timerqueue.o
> >     CC      lib/vsprintf.o
> >     lib/string.c: In function 'strstr':
> >     lib/string.c:478:8: error: inlining failed in call to
> >     always_inline 'strlen': function not inlinable
> >     lib/string.c:903:5: error: called from here
> >     lib/string.c:478:8: error: inlining failed in call to
> >     always_inline 'strlen': function not inlinable
> >     lib/string.c:906:5: error: called from here
> >     lib/string.c:855:15: error: inlining failed in call to
> >     always_inline 'memcmp': function not inlinable
> >     ...
> > pavel@duo:/data/l/linux-next-n900$ git branch -l
> > * (detached from next-20180403)
> > 
> > I'm using
> > 
> > eval ` eldk-switch.sh -r 5.4 armv7a`
> > 
> > for cross-compilation.
> 
> Hmm I'm not seeing build issues with next-20180404, did this somehow
> already get sorted out?

Let me check...

  CC      lib/vsprintf.o
  lib/string.c: In function 'strstr':
  lib/string.c:478:8: error: inlining failed in call to always_inline
  'strlen': function not inlinable

Same problem.

pavel@duo:~$ eval ` eldk-switch.sh -r 5.4 armv7a`
pavel@duo:~$ arm-linux-gnueabi-gcc --version
arm-linux-gnueabi-gcc (GCC) 4.7.2

Best regards,								Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: ARM compile failure in Re: linux-next: Tree for Apr 4

[Pavel Machek]

[-- Attachment #1.1: Type: text/plain, Size: 1220 bytes --]

Hi!

> > When trying to build kernel for N900, I get:
> > 
> >   CC      lib/timerqueue.o
> >     CC      lib/vsprintf.o
> >     lib/string.c: In function 'strstr':
> >     lib/string.c:478:8: error: inlining failed in call to
> >     always_inline 'strlen': function not inlinable
> >     lib/string.c:903:5: error: called from here
> >     lib/string.c:478:8: error: inlining failed in call to
> >     always_inline 'strlen': function not inlinable
> >     lib/string.c:906:5: error: called from here
> >     lib/string.c:855:15: error: inlining failed in call to
> >     always_inline 'memcmp': function not inlinable
> >     ...
> > pavel@duo:/data/l/linux-next-n900$ git branch -l
> > * (detached from next-20180403)
> > 
> > I'm using
> > 
> > eval ` eldk-switch.sh -r 5.4 armv7a`
> > 
> > for cross-compilation.
> 
> Hmm I'm not seeing build issues with next-20180404, did this somehow
> already get sorted out?

It seems it is config-dependend. omap2plus_defconfig compiles ok for
me.

Can you try with attached .config?

									Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #1.2: config.ok.gz --]
[-- Type: application/gzip, Size: 25181 bytes --]

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: ARM compile failure in Re: linux-next: Tree for Apr 4

[Tony Lindgren]

* Pavel Machek <pavel@ucw.cz> [180404 18:47]:
> Hi!
> 
> > > When trying to build kernel for N900, I get:
> > > 
> > >   CC      lib/timerqueue.o
> > >     CC      lib/vsprintf.o
> > >     lib/string.c: In function 'strstr':
> > >     lib/string.c:478:8: error: inlining failed in call to
> > >     always_inline 'strlen': function not inlinable
> > >     lib/string.c:903:5: error: called from here
> > >     lib/string.c:478:8: error: inlining failed in call to
> > >     always_inline 'strlen': function not inlinable
> > >     lib/string.c:906:5: error: called from here
> > >     lib/string.c:855:15: error: inlining failed in call to
> > >     always_inline 'memcmp': function not inlinable
> > >     ...
> > > pavel@duo:/data/l/linux-next-n900$ git branch -l
> > > * (detached from next-20180403)
> > > 
> > > I'm using
> > > 
> > > eval ` eldk-switch.sh -r 5.4 armv7a`
> > > 
> > > for cross-compilation.
> > 
> > Hmm I'm not seeing build issues with next-20180404, did this somehow
> > already get sorted out?
> 
> It seems it is config-dependend. omap2plus_defconfig compiles ok for
> me.
> 
> Can you try with attached .config?

That still builds for me. This with plain gcc-7.3.0 binutils-2.30
built with buildall script.

Regards,

Tony

FORTIFY_SOURCE breaks ARM compilation in -next -- was Re: ARM compile failure in Re: linux-next: Tree for Apr 4

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 2916 bytes --]

On Wed 2018-04-04 12:59:51, Tony Lindgren wrote:
> * Pavel Machek <pavel@ucw.cz> [180404 18:47]:
> > Hi!
> > 
> > > > When trying to build kernel for N900, I get:
> > > > 
> > > >   CC      lib/timerqueue.o
> > > >     CC      lib/vsprintf.o
> > > >     lib/string.c: In function 'strstr':
> > > >     lib/string.c:478:8: error: inlining failed in call to
> > > >     always_inline 'strlen': function not inlinable
> > > >     lib/string.c:903:5: error: called from here
> > > >     lib/string.c:478:8: error: inlining failed in call to
> > > >     always_inline 'strlen': function not inlinable
> > > >     lib/string.c:906:5: error: called from here
> > > >     lib/string.c:855:15: error: inlining failed in call to
> > > >     always_inline 'memcmp': function not inlinable
> > > >     ...
> > > > pavel@duo:/data/l/linux-next-n900$ git branch -l
> > > > * (detached from next-20180403)
> > > > 
> > > > I'm using
> > > > 
> > > > eval ` eldk-switch.sh -r 5.4 armv7a`
> > > > 
> > > > for cross-compilation.
> > > 
> > > Hmm I'm not seeing build issues with next-20180404, did this somehow
> > > already get sorted out?
> > 
> > It seems it is config-dependend. omap2plus_defconfig compiles ok for
> > me.
> > 
> > Can you try with attached .config?
> 
> That still builds for me. This with plain gcc-7.3.0 binutils-2.30
> built with buildall script.

Thanks.

Ok, let me try to bisect it. Compile-problem should be easy...

Hmm. And as it is compile-problem in single file, it should even be
reasonably fast. I did not realize how easy it would be:

#!/bin/bash
set -e
cp config.ok .config
yes '' | ARCH=arm make lib/string.o

And the winner is:

ee333554fed55555a986a90bb097ac7f9d6f05bf is the first bad commit
commit ee333554fed55555a986a90bb097ac7f9d6f05bf
Author: Jinbum Park <jinb.park7@gmail.com>
Date:   Tue Mar 6 01:39:24 2018 +0100

    ARM: 8749/1: Kconfig: Add ARCH_HAS_FORTIFY_SOURCE

    CONFIG_FORTIFY_SOURCE detects various overflows at compile-time.
        (6974f0c4555e ("include/linux/string.h:
    add the option of fortified string.h functions)
    
    ARCH_HAS_FORTIFY_SOURCE means that the architecture can be built
    and
    run with CONFIG_FORTIFY_SOURCE.
    
    Since ARM can be built and run with that flag like other
    architectures,
    select ARCH_HAS_FORTIFY_SOURCE as default.
    
    Acked-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Jinbum Park <jinb.park7@gmail.com>
    Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>

:040000 040000 2bff2f75ba36dd838a8ded3028b745d9f13f4c4a
									e61289e33a1fb71b1a6c05c442d45ea40bd5aba0
									M
									arch
bisect run success
pavel@duo:/data/l/linux-next-n900$ 


									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

[regression v4.17-rc0] Re: FORTIFY_SOURCE breaks ARM compilation in -next -- was Re: ARM compile failure in Re: linux-next: Tree for Apr 4

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 1285 bytes --]

Hi!

> Thanks.
> 
> Ok, let me try to bisect it. Compile-problem should be easy...
> 
> Hmm. And as it is compile-problem in single file, it should even be
> reasonably fast. I did not realize how easy it would be:
> 
> #!/bin/bash
> set -e
> cp config.ok .config
> yes '' | ARCH=arm make lib/string.o
> 
> And the winner is:
> 
> ee333554fed55555a986a90bb097ac7f9d6f05bf is the first bad commit
> commit ee333554fed55555a986a90bb097ac7f9d6f05bf
> Author: Jinbum Park <jinb.park7@gmail.com>
> Date:   Tue Mar 6 01:39:24 2018 +0100
...

>     Acked-by: Kees Cook <keescook@chromium.org>
>     Signed-off-by: Jinbum Park <jinb.park7@gmail.com>
>     Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>

So I bisect a problem in -next, and patch is merged to Linus,
_anyway_, breaking compilation there? Neither Jinbum nor Russell even
bother to comment.

And BTW, Russell, there's another regression I bisected to your
commit, that one is like two releases old, and "only" causes
compilation warnings during build with non-US locale. I even proposed
fix for that. Guess what? Ignored too.


									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [regression v4.17-rc0] Re: FORTIFY_SOURCE breaks ARM compilation in -next -- was Re: ARM compile failure in Re: linux-next: Tree for Apr 4

[Kees Cook]

On Sun, Apr 15, 2018 at 10:39 AM, Pavel Machek <pavel@ucw.cz> wrote:
> Hi!
>
>> Thanks.
>>
>> Ok, let me try to bisect it. Compile-problem should be easy...
>>
>> Hmm. And as it is compile-problem in single file, it should even be
>> reasonably fast. I did not realize how easy it would be:
>>
>> #!/bin/bash
>> set -e
>> cp config.ok .config
>> yes '' | ARCH=arm make lib/string.o
>>
>> And the winner is:
>>
>> ee333554fed55555a986a90bb097ac7f9d6f05bf is the first bad commit
>> commit ee333554fed55555a986a90bb097ac7f9d6f05bf
>> Author: Jinbum Park <jinb.park7@gmail.com>
>> Date:   Tue Mar 6 01:39:24 2018 +0100
> ...
>
>>     Acked-by: Kees Cook <keescook@chromium.org>
>>     Signed-off-by: Jinbum Park <jinb.park7@gmail.com>
>>     Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
>
> So I bisect a problem in -next, and patch is merged to Linus,
> _anyway_, breaking compilation there? Neither Jinbum nor Russell even
> bother to comment.

Hi! Sorry I lost this email in my inbox. It seems this is specific to
a particular subset of arm architectures? (My local builds of arm all
succeed, for example. Can you send your failing config?) I'll take a
closer look on Monday if Daniel doesn't beat me to it.

-Kees

>
> And BTW, Russell, there's another regression I bisected to your
> commit, that one is like two releases old, and "only" causes
> compilation warnings during build with non-US locale. I even proposed
> fix for that. Guess what? Ignored too.
>
>
>                                                                         Pavel
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html



-- 
Kees Cook
Pixel Security

Re: [regression v4.17-rc0] Re: FORTIFY_SOURCE breaks ARM compilation in -next -- was Re: ARM compile failure in Re: linux-next: Tree for Apr 4

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 1702 bytes --]

On Sun 2018-04-15 11:00:06, Kees Cook wrote:
> On Sun, Apr 15, 2018 at 10:39 AM, Pavel Machek <pavel@ucw.cz> wrote:
> > Hi!
> >
> >> Thanks.
> >>
> >> Ok, let me try to bisect it. Compile-problem should be easy...
> >>
> >> Hmm. And as it is compile-problem in single file, it should even be
> >> reasonably fast. I did not realize how easy it would be:
> >>
> >> #!/bin/bash
> >> set -e
> >> cp config.ok .config
> >> yes '' | ARCH=arm make lib/string.o
> >>
> >> And the winner is:
> >>
> >> ee333554fed55555a986a90bb097ac7f9d6f05bf is the first bad commit
> >> commit ee333554fed55555a986a90bb097ac7f9d6f05bf
> >> Author: Jinbum Park <jinb.park7@gmail.com>
> >> Date:   Tue Mar 6 01:39:24 2018 +0100
> > ...
> >
> >>     Acked-by: Kees Cook <keescook@chromium.org>
> >>     Signed-off-by: Jinbum Park <jinb.park7@gmail.com>
> >>     Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
> >
> > So I bisect a problem in -next, and patch is merged to Linus,
> > _anyway_, breaking compilation there? Neither Jinbum nor Russell even
> > bother to comment.
> 
> Hi! Sorry I lost this email in my inbox. It seems this is specific to
> a particular subset of arm architectures? (My local builds of arm all
> succeed, for example. Can you send your failing config?) I'll take a
> closer look on Monday if Daniel doesn't beat me to it.

I believe it depends on gcc version really. I should get some sleep
now, but details should be in the corresponding thread on lkml.

I'll send you my .config privately.
								Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [regression v4.17-rc0] Re: FORTIFY_SOURCE breaks ARM compilation in -next -- was Re: ARM compile failure in Re: linux-next: Tree for Apr 4

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 1615 bytes --]

On Sun 2018-04-15 11:00:06, Kees Cook wrote:
> On Sun, Apr 15, 2018 at 10:39 AM, Pavel Machek <pavel@ucw.cz> wrote:
> > Hi!
> >
> >> Thanks.
> >>
> >> Ok, let me try to bisect it. Compile-problem should be easy...
> >>
> >> Hmm. And as it is compile-problem in single file, it should even be
> >> reasonably fast. I did not realize how easy it would be:
> >>
> >> #!/bin/bash
> >> set -e
> >> cp config.ok .config
> >> yes '' | ARCH=arm make lib/string.o
> >>
> >> And the winner is:
> >>
> >> ee333554fed55555a986a90bb097ac7f9d6f05bf is the first bad commit
> >> commit ee333554fed55555a986a90bb097ac7f9d6f05bf
> >> Author: Jinbum Park <jinb.park7@gmail.com>
> >> Date:   Tue Mar 6 01:39:24 2018 +0100
> > ...
> >
> >>     Acked-by: Kees Cook <keescook@chromium.org>
> >>     Signed-off-by: Jinbum Park <jinb.park7@gmail.com>
> >>     Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
> >
> > So I bisect a problem in -next, and patch is merged to Linus,
> > _anyway_, breaking compilation there? Neither Jinbum nor Russell even
> > bother to comment.
> 
> Hi! Sorry I lost this email in my inbox. It seems this is specific to
> a particular subset of arm architectures? (My local builds of arm all
> succeed, for example. Can you send your failing config?) I'll take a
> closer look on Monday if Daniel doesn't beat me to it.

Daniel, Kees: any news?

I'm aware you did not specify which Monday :-).
									Pavel
									
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [regression v4.17-rc0] Re: FORTIFY_SOURCE breaks ARM compilation in -next -- was Re: ARM compile failure in Re: linux-next: Tree for Apr 4

[Kees Cook]

On Fri, Apr 20, 2018 at 12:34 AM, Pavel Machek <pavel@ucw.cz> wrote:
> On Sun 2018-04-15 11:00:06, Kees Cook wrote:
>> On Sun, Apr 15, 2018 at 10:39 AM, Pavel Machek <pavel@ucw.cz> wrote:
>> > Hi!
>> >
>> >> Thanks.
>> >>
>> >> Ok, let me try to bisect it. Compile-problem should be easy...
>> >>
>> >> Hmm. And as it is compile-problem in single file, it should even be
>> >> reasonably fast. I did not realize how easy it would be:
>> >>
>> >> #!/bin/bash
>> >> set -e
>> >> cp config.ok .config
>> >> yes '' | ARCH=arm make lib/string.o
>> >>
>> >> And the winner is:
>> >>
>> >> ee333554fed55555a986a90bb097ac7f9d6f05bf is the first bad commit
>> >> commit ee333554fed55555a986a90bb097ac7f9d6f05bf
>> >> Author: Jinbum Park <jinb.park7@gmail.com>
>> >> Date:   Tue Mar 6 01:39:24 2018 +0100
>> > ...
>> >
>> >>     Acked-by: Kees Cook <keescook@chromium.org>
>> >>     Signed-off-by: Jinbum Park <jinb.park7@gmail.com>
>> >>     Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
>> >
>> > So I bisect a problem in -next, and patch is merged to Linus,
>> > _anyway_, breaking compilation there? Neither Jinbum nor Russell even
>> > bother to comment.
>>
>> Hi! Sorry I lost this email in my inbox. It seems this is specific to
>> a particular subset of arm architectures? (My local builds of arm all
>> succeed, for example. Can you send your failing config?) I'll take a
>> closer look on Monday if Daniel doesn't beat me to it.
>
> Daniel, Kees: any news?
>
> I'm aware you did not specify which Monday :-).

Hi! Sorry, I got distracted. So the .config you sent me builds fine
with my cross compiler. I suspect this is something specific to ELDK's
compiler. I can try some other compiler versions. What version of gcc
is failing?

-Kees

-- 
Kees Cook
Pixel Security

Re: [regression v4.17-rc0] Re: FORTIFY_SOURCE breaks ARM compilation in -next -- was Re: ARM compile failure in Re: linux-next: Tree for Apr 4

[Russell King - ARM Linux]

On Fri, Apr 20, 2018 at 08:05:17AM -0700, Kees Cook wrote:
> On Fri, Apr 20, 2018 at 12:34 AM, Pavel Machek <pavel@ucw.cz> wrote:
> > On Sun 2018-04-15 11:00:06, Kees Cook wrote:
> >> On Sun, Apr 15, 2018 at 10:39 AM, Pavel Machek <pavel@ucw.cz> wrote:
> >> > Hi!
> >> >
> >> >> Thanks.
> >> >>
> >> >> Ok, let me try to bisect it. Compile-problem should be easy...
> >> >>
> >> >> Hmm. And as it is compile-problem in single file, it should even be
> >> >> reasonably fast. I did not realize how easy it would be:
> >> >>
> >> >> #!/bin/bash
> >> >> set -e
> >> >> cp config.ok .config
> >> >> yes '' | ARCH=arm make lib/string.o
> >> >>
> >> >> And the winner is:
> >> >>
> >> >> ee333554fed55555a986a90bb097ac7f9d6f05bf is the first bad commit
> >> >> commit ee333554fed55555a986a90bb097ac7f9d6f05bf
> >> >> Author: Jinbum Park <jinb.park7@gmail.com>
> >> >> Date:   Tue Mar 6 01:39:24 2018 +0100
> >> > ...
> >> >
> >> >>     Acked-by: Kees Cook <keescook@chromium.org>
> >> >>     Signed-off-by: Jinbum Park <jinb.park7@gmail.com>
> >> >>     Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
> >> >
> >> > So I bisect a problem in -next, and patch is merged to Linus,
> >> > _anyway_, breaking compilation there? Neither Jinbum nor Russell even
> >> > bother to comment.
> >>
> >> Hi! Sorry I lost this email in my inbox. It seems this is specific to
> >> a particular subset of arm architectures? (My local builds of arm all
> >> succeed, for example. Can you send your failing config?) I'll take a
> >> closer look on Monday if Daniel doesn't beat me to it.
> >
> > Daniel, Kees: any news?
> >
> > I'm aware you did not specify which Monday :-).
> 
> Hi! Sorry, I got distracted. So the .config you sent me builds fine
> with my cross compiler. I suspect this is something specific to ELDK's
> compiler. I can try some other compiler versions. What version of gcc
> is failing?

Hi Kees,

We know it works fine with:

linux-next's gcc 4.6.3 + binutils 2.22
my gcc 4.7.4 + binutils 2.25
kernelci.org's Linaro GCC 5.3-2016.05 toolchain (gcc 5.3.1 20160412)
Tony's using gcc 7.3.0 + binutils 2.30
Arnd's using mostly gcc 8.0.1 + binutils 2.29
What-ever toolchain Olof's autobuilder is using

which is quite a spread of versions, both binutils and gcc, and they
all work.  The autobuilders plus Arnd's are regularly verifying lots
of kernel trees (including my own) with lots of configurations, and
the identified patch has not reproduced this compile failure there.

Searching google for:

lib/string.c "error: inlining failed in call to always_inline 'strlen': function not inlinable"

gives me only three hits on mail-archive.com for this, all of them
are Pavel's email or a reply to it.  There appears to be no other
reports of compile failure anywhere else on the google-crawled
Internet.

There appears to be no information readily available as to what
compiler versions each ELDK version contains (see
http://www.denx.de/wiki/view/ELDK-5) so providing the eldk-switch
command to us gives us no useful information.

I think more information about Pavel's setup is needed, including:

* compiler version
* environment (any kernel build specific environment variables set?)
* exact make command line

Maybe even showing the exact command used by kbuild to invoke the
C compiler for lib/string.c.

It could simply be a bug in the ELDK GCC version that Pavel's using.
Could it be that DENX have patched gcc for ELDK and subtly broken
it?  We all know distros like to apply patches to packages.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up

Re: [regression v4.17-rc0] Re: FORTIFY_SOURCE breaks ARM compilation in -next -- was Re: ARM compile failure in Re: linux-next: Tree for Apr 4

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 1396 bytes --]

Hi!

> >> Hi! Sorry I lost this email in my inbox. It seems this is specific to
> >> a particular subset of arm architectures? (My local builds of arm all
> >> succeed, for example. Can you send your failing config?) I'll take a
> >> closer look on Monday if Daniel doesn't beat me to it.
> >
> > Daniel, Kees: any news?
> >
> > I'm aware you did not specify which Monday :-).
> 
> Hi! Sorry, I got distracted. So the .config you sent me builds fine
> with my cross compiler. I suspect this is something specific to ELDK's
> compiler. I can try some other compiler versions. What version of gcc
> is failing?

I have:

pavel@duo:/data/l/linux-n900$ arm-linux-gnueabi-gcc --version
arm-linux-gnueabi-gcc (GCC) 4.7.2
Copyright (C) 2012 Free Software Foundation, Inc.
pavel@duo:/data/l/linux-n900$ arm-linux-gnueabi-ld --version
GNU ld (GNU Binutils) 2.23.1.20121113
Copyright 2012 Free Software Foundation, Inc.

Let me try with eldk-5.6:

pavel@duo:/data/l/linux-n900$ arm-linux-gnueabi-gcc --version
arm-linux-gnueabi-gcc (GCC) 4.8.2
pavel@duo:/data/l/linux-n900$ arm-linux-gnueabi-ld --version
GNU ld (GNU Binutils) 2.24

make  lib/string.o

Seems to succeed, so I guess full build will succeed, too...

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [regression v4.17-rc0] Re: FORTIFY_SOURCE breaks ARM compilation in -next -- was Re: ARM compile failure in Re: linux-next: Tree for Apr 4

[Daniel Micay]

On 20 April 2018 at 15:15, Pavel Machek <pavel@ucw.cz> wrote:
> Hi!
>
>> >> Hi! Sorry I lost this email in my inbox. It seems this is specific to
>> >> a particular subset of arm architectures? (My local builds of arm all
>> >> succeed, for example. Can you send your failing config?) I'll take a
>> >> closer look on Monday if Daniel doesn't beat me to it.
>> >
>> > Daniel, Kees: any news?
>> >
>> > I'm aware you did not specify which Monday :-).
>>
>> Hi! Sorry, I got distracted. So the .config you sent me builds fine
>> with my cross compiler. I suspect this is something specific to ELDK's
>> compiler. I can try some other compiler versions. What version of gcc
>> is failing?
>
> I have:
>
> pavel@duo:/data/l/linux-n900$ arm-linux-gnueabi-gcc --version
> arm-linux-gnueabi-gcc (GCC) 4.7.2
> Copyright (C) 2012 Free Software Foundation, Inc.
> pavel@duo:/data/l/linux-n900$ arm-linux-gnueabi-ld --version
> GNU ld (GNU Binutils) 2.23.1.20121113
> Copyright 2012 Free Software Foundation, Inc.
>
> Let me try with eldk-5.6:
>
> pavel@duo:/data/l/linux-n900$ arm-linux-gnueabi-gcc --version
> arm-linux-gnueabi-gcc (GCC) 4.8.2
> pavel@duo:/data/l/linux-n900$ arm-linux-gnueabi-ld --version
> GNU ld (GNU Binutils) 2.24
>
> make  lib/string.o
>
> Seems to succeed, so I guess full build will succeed, too...

It doesn't imply that a full build would work.

Re: [regression v4.17-rc0] Re: FORTIFY_SOURCE breaks ARM compilation in -next -- was Re: ARM compile failure in Re: linux-next: Tree for Apr 4

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 2210 bytes --]

On Fri 2018-04-20 15:18:32, Daniel Micay wrote:
> On 20 April 2018 at 15:15, Pavel Machek <pavel@ucw.cz> wrote:
> > Hi!
> >
> >> >> Hi! Sorry I lost this email in my inbox. It seems this is specific to
> >> >> a particular subset of arm architectures? (My local builds of arm all
> >> >> succeed, for example. Can you send your failing config?) I'll take a
> >> >> closer look on Monday if Daniel doesn't beat me to it.
> >> >
> >> > Daniel, Kees: any news?
> >> >
> >> > I'm aware you did not specify which Monday :-).
> >>
> >> Hi! Sorry, I got distracted. So the .config you sent me builds fine
> >> with my cross compiler. I suspect this is something specific to ELDK's
> >> compiler. I can try some other compiler versions. What version of gcc
> >> is failing?
> >
> > I have:
> >
> > pavel@duo:/data/l/linux-n900$ arm-linux-gnueabi-gcc --version
> > arm-linux-gnueabi-gcc (GCC) 4.7.2
> > Copyright (C) 2012 Free Software Foundation, Inc.
> > pavel@duo:/data/l/linux-n900$ arm-linux-gnueabi-ld --version
> > GNU ld (GNU Binutils) 2.23.1.20121113
> > Copyright 2012 Free Software Foundation, Inc.
> >
> > Let me try with eldk-5.6:
> >
> > pavel@duo:/data/l/linux-n900$ arm-linux-gnueabi-gcc --version
> > arm-linux-gnueabi-gcc (GCC) 4.8.2
> > pavel@duo:/data/l/linux-n900$ arm-linux-gnueabi-ld --version
> > GNU ld (GNU Binutils) 2.24
> >
> > make  lib/string.o
> >
> > Seems to succeed, so I guess full build will succeed, too...
> 
> It doesn't imply that a full build would work.

You are right. eldk-5.6 does not have problem with string.o, but does
not compile the kernel, either...

  CC      arch/arm/kernel/asm-offsets.s
  arch/arm/kernel/asm-offsets.c:56:2: error: #error Your compiler is
  too buggy; it is known to miscompile kernels
   #error Your compiler is too buggy; it is known to miscompile
  kernels
    ^
    arch/arm/kernel/asm-offsets.c:57:2: error: #error and result in
  filesystem corruption and oopses.
   #error and result in filesystem corruption and oopses.
     ^

									Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [regression v4.17-rc0] Re: FORTIFY_SOURCE breaks ARM compilation in -next -- was Re: ARM compile failure in Re: linux-next: Tree for Apr 4

[Daniel Micay]

Well, that's not related, it's just this:

#ifdef __GNUC__
#if (__GNUC__ == 3 && __GNUC_MINOR__ < 3)
#error Your compiler is too buggy; it is known to miscompile kernels.
#error    Known good compilers: 3.3, 4.x
#endif
#if GCC_VERSION >= 40800 && GCC_VERSION < 40803
#error Your compiler is too buggy; it is known to miscompile kernels
#error and result in filesystem corruption and oopses.
#endif
#endif

Re: [regression v4.17-rc0] Re: FORTIFY_SOURCE breaks ARM compilation in -next -- was Re: ARM compile failure in Re: linux-next: Tree for Apr 4

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 728 bytes --]

On Fri 2018-04-20 15:30:03, Daniel Micay wrote:
> Well, that's not related, it's just this:
> 
> #ifdef __GNUC__
> #if (__GNUC__ == 3 && __GNUC_MINOR__ < 3)
> #error Your compiler is too buggy; it is known to miscompile kernels.
> #error    Known good compilers: 3.3, 4.x
> #endif
> #if GCC_VERSION >= 40800 && GCC_VERSION < 40803
> #error Your compiler is too buggy; it is known to miscompile kernels
> #error and result in filesystem corruption and oopses.
> #endif
> #endif

Yeah, I know. I guess the kernel would compile if I removed those
checks... 

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]