ARM: pxa/corgi: armv5te kernel 4.12 fails to decompress compiled with gcc7

[Andrea Adami]

Hello,

with the same toolchain, only changing from gcc6.3.0 to gcc7.1.0, the
kernel does not boot: using xz the decompression fails with
"XZ-compressed data is corrupt" / XZ_DATA_ERROR.

I think it might be this line in lib/xz/xz_dec_stream.c

s->vli |= (vli_type)(byte & 0x7F) << s->pos;

Here gcc6 is using __aeabi_llsl

Looking at the disassembled sources, do you see evident issues in dec_vli()?
Kernel is built optimized for size. I am uploading the logs and huge
build dirs [1]

Pls look under /disassembled. Suffix is the gcc version.

decompress6.S -> built with gcc6
decompress7.S -> built with gcc7

I am puzzled because the same toolchain produces valid kernel for
qemuarm versatile-926ejs.

Finally, a short test with gzip compressed kernel shows it does not
boot as well so maybe the issue is another. I don't have serial here
now but I'll take more logs if necessary.

Thanks
Andrea

[1] https://github.com/andrea-adami/gcc7-kernel-debug

[Robert Jarzmik]

Post by Andrea Adami
Hello,

Hi Andrea,

I have the same report on userspace side on buildroot from Petr [1], which
triggers endless segfaults in userspace (init) with gcc7 while everything is
fine with gcc6. I have confirmation on my test farm the problem happens as well.

Since debugging in userspace is far easier, I would suggest attacking the debug
with Petr on userspace side, and once sorted out, come back to kernel side.

Cheers.

--
Robert

[1] Mail from Petr
From: Petr Cvek <***@gmail.com>
Subject: cross-gcc
To: ***@free.fr
Date: Wed, 12 Jul 2017 02:37:35 +0200 (1 week, 1 day, 6 hours ago)
Message-ID: <ea45c82f-35a8-a908-d199-***@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1

Hi,

do you still have a PXA27x board? I'm trying to build a rootfs with a new GCC
(7.1 from crosstool-ng snapshot a few days ago, buildroot same way) and it keeps
segfaulting (busybox, sshd, udevd, Xorg). Do you have the same problem? (seems
it does not care for xscale/iwmmxt neither O1/O2/Os, maybe on O0).

The GCC 6.x was fine and if i will need to make a bug report I think I will need
confirmation.