Kernel Sources is failing to build with gcc 7.2

Hello

I’ve tried to build with the latest yocto branch “rocko”. and they rely on gcc 7.2
Kernel sources have failed to build with the following error messages:

kernel-source/arch/arm64/kernel/topology.c:114:40: error: '%d' directive output may be truncated writing between 1 and 10 bytes into a region of size 3 [-Werror=format-truncation= |    snprintf(name, sizeof(name), "cluster%d", i);

kernel-source/arch/arm64/kernel/topology.c:114:32: note: directive argument in the range [0, 2147483647] |    snprintf(name, sizeof(name), "cluster%d", i);

kernel-source/arch/arm64/kernel/topology.c:114:3: note: 'snprintf' output between 9 and 18 bytes into a destination of size 10 |    snprintf(name, sizeof(name), "cluster%d", i);

Is there any time plans to fix those kernel source for gcc 7.2. It’s better to not have patches and fix the upstream.
Thanks

Hi bassem.nomany,

Sorry that we don’t support gcc 7.2 yet. I’ll check with internal team for this. Thanks!

FYI, there are a lot of new warnings in gcc 7. If you go to the top level Makefile, find the lines with:

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,)

…and then append below this:

# FIXME TODO
KBUILD_CFLAGS   += $(call cc-disable-warning, format-truncation)
KBUILD_CFLAGS   += $(call cc-disable-warning, format-overflow)
KBUILD_CFLAGS   += $(call cc-disable-warning, int-in-bool-context)

…those warnings will go away.

Unfortunately I ran into a lot of other new warnings treated as errors, plus I don’t know if the disabled warnings actually have meaning or not…there might be reason for those warnings.

One of the major culprits seems to be something related to an accidental use of _initconst where const was already used…and the newer compiler doesn’t like it. The first “const” on those lines can be removed (though once again I don’t know if this is actually a good thing to do).

There was a memset warning treated as error in dc.c which I didn’t try to work around.

Hi linuxdev and bassem.nomany,

Are you users keeping updating the toolchain version? If more and more users are trying latest gcc, I should push internal team to follow as well.

@linuxdev Thanks for the help. I will patch the sources for now.

@WayneWWW The thing is many developers rely on the yocto project as a build system and an Integration tool when it comes to building embedded Linux distros.
Yocto switched to gcc 7.2 with their latest release rocko. which I think many developers would use.

It’s always a good idea to stay up to date with the latest toolchain to get the latest bug and security fixes and better optimizations.

So As a temp solution I can dirty-patch the sources to disable treating warnings as errors. but I prefer if the sources were validated for those warnings and check if they have any impact on the logic or the memory. otherwise suppress them.

aarch64 cross tools on Fedora, via the regular repositories, are:

> aarch64-linux-gnu-gcc --version
aarch64-linux-gnu-gcc (GCC) 7.2.1 20170915 (Red Hat Cross 7.2.1-1)

This isn’t even requiring a custom download or install, it’s “just available”.

This is also the same series (7.x) used on most distributions now for x86_64.

This is just opinion, but I’ve been monitoring the Linaro developer list for release announcements for several years, and there are a number of reasons why the 7.x series is actually better than the 4.x or even 5.x or 6.x series (especially on arm64/aarch64). There was in fact an ABI issue fixed which may show up at times when looking at code generated from older gcc (without the newer compiler you won’t know when you run into this). Here is an excerpt of one of the announcements from Linaro:

The Linaro Toolchain Working Group (TCWG) is pleased to announce the 2017.11
snapshot of Linaro GCC 6 and 7 source packages.

o The GCC 7 series introduced an ABI change for ARM targets by fixing a bug
(present since GCC 5, see link below) that affects conformance to the procedure
call standard (AAPCS).  The bug affects some C++ code where class objects are
passed by value to functions and could result in incorrect or inconsistent code
being generated. If the option -Wpsabi is enabled (on by default) the compiler
will emit a diagnostic note for code that might be affected by this ABI change.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77728

I believe in the long run, or even not too far in the future, being able to work with this newer gcc will only be a benefit.

@linuxdev I like you have good facts :thumbsup:

For what it’s worth, I’ve compiled 28.2-rc with Linaro 2017.11, which is gcc-7.2, and it booted and the networking worked. The three warnings @linuxdev disabled are also disabled in the latest Linux kernel tree upstream.

I’ve done no other tests and I use the default toolchain in my day-to-day work.

Yea, Right now. I have done the same as above. and using it within yocto platform build system. Just disabled the warnings. and It works fine. so as It seems.

Dear All,

I just would like to share my experience. Perhaps it may be useful for you.
snprintf() should not generate format-truncation warning because it is safe unlike sprintf().
However we can see such warnings using gcc-7.

@linuxdev proposed a solution changing a bit a root Makefile. It is OK.
However some people may want to keep the kernel source tree unchanged.
It can be done using make parameters: CFLAGS_KERNEL and etc.

Please be aware CFLAGS_KERNEL is a parameter, it cannot be exported as environmental variable!
Unlike of ARCH= CROSS_COMPILE= or CROSS32CC= It should be specified in the make cmd line explicitly.
By the way O= and INSTALL_PATH= are also parameters, but not env variables.

Please remember about double quotation marks to preserve spaces between gcc directives.

Sample build script (kernel-4.4 TX1):

#!/bin/sh

BUILD_PATH=../.build
INSTALL_PATH=../.out

KERNEL_PATH=kernel-4.4

[ -d $KERNEL_PATH ] && cd $KERNEL_PATH || exit

[ -d $BUILD_PATH ] || mkdir $BUILD_PATH
[ -d $INSTALL_PATH ] || mkdir $INSTALL_PATH

export ARCH=arm64
export CROSS_COMPILE=aarch64-linux-gnu-
export CROSS32CC=/usr/bin/arm-linux-gnueabihf-gcc

CFLAGS_KERNEL=-Wno-error=memset-elt-size\ -Wno-error=format-truncation\ -Wno-error=int-in-bool-context\ -Wno-error=format-overflow

export CONFIG_LOCALVERSION_AUTO=y

make O=$BUILD_PATH INSTALL_PATH=$INSTALL_PATH mrproper
make O=$BUILD_PATH INSTALL_PATH=$INSTALL_PATH tegra21_defconfig
make O=$BUILD_PATH INSTALL_PATH=$INSTALL_PATH CFLAGS_KERNEL="$CFLAGS_KERNEL" -j$(nproc)
make O=$BUILD_PATH INSTALL_PATH=$INSTALL_PATH CFLAGS_KERNEL="$CFLAGS_KERNEL" install
make O=$BUILD_PATH INSTALL_MOD_PATH=$INSTALL_PATH CFLAGS_KERNEL="$CFLAGS_KERNEL" modules_install

GITHASH=$(cat $BUILD_PATH/include/generated/utsrelease.h | awk '{print $3}' | sed -e 's/"//g')

DTB=$BUILD_PATH/arch/arm64/boot/dts/tegra210-jetson-tx1-p2597-2180-a01-devkit.dtb
[ -f $DTB ] && cp  $DTB $INSTALL_PATH/ || echo DTB is missing

cd ..

It is also a good idea to set CONFIG_LOCALVERSION_AUTO=y to have a kernel image signed with a git hash.
So, you have a chance to see with uname -r which version of kernel is currently running.
I have no idea why NVIDIA doesn’t use it.

Sincerely,
Alex

Past kernels have used the githash, but the source_sync.sh script now downloads some out-of-tree components. I’m unsure, but will speculate that perhaps the out of tree components are not in the same git repository.

Added note: When one does change CONFIG_LOCALVERSION, the implication is that the modules will be searched for in a different location. Beware of the need to build and install modules as well if the CONFIG_LOCALVERSION changes (the result is a change in the suffix of “uname -r”, and modules are searched for at “/lib/modules/$(uname -r)/”).

You are right indeed. Some out-of-tree components required for building the kernel are from different git repositories. But from my point of view it is better than nothing.
I mean, when you run some different kernels on your debugging system or should recognize an issue at the client side it is nice to have a bit more than guess…
Normally we make in our company a super project which aggregates all the repositories as submodules providing a consistency of the project. But it is another story.

Regarding the note, agree. But again, for me it is normal situation.