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@xxxxxx> wrote: > > On Sun 2018-04-15 11:00:06, Kees Cook wrote: > >> On Sun, Apr 15, 2018 at 10:39 AM, Pavel Machek <pavel@xxxxxx> 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@xxxxxxxxx> > >> >> Date: Tue Mar 6 01:39:24 2018 +0100 > >> > ... > >> > > >> >> Acked-by: Kees Cook <keescook@xxxxxxxxxxxx> > >> >> Signed-off-by: Jinbum Park <jinb.park7@xxxxxxxxx> > >> >> Signed-off-by: Russell King <rmk+kernel@xxxxxxxxxxxxxxx> > >> > > >> > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-next" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
