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

[Petr Cvek]

Hi,

Dne 15.10.2017 v 12:46 Aaro Koskinen napsal(a):
> Hi,
> 
> On Sat, Oct 14, 2017 at 11:57:30PM +0200, Robert Jarzmik wrote:
>> Aaro Koskinen <aaro.koskinen at iki.fi> writes:
>>> On Sat, Sep 02, 2017 at 11:50:55PM +0200, Andrea Adami wrote:
>>>> On Thu, Jul 20, 2017 at 8:57 AM, Robert Jarzmik <robert.jarzmik at free.fr> wrote:
>>>>> Andrea Adami <andrea.adami at gmail.com> writes:
>>>>> 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.
>>>>
>>>> sorry for the delay, I was awaiting to test gcc 7.2 and binutils 2.29.
>>>> Unfortunately, same issue: XZ-compressed data is corrupt - System Halted.
>>>
>>> Has anyone been able to debug this further? It seems there are also issues
>>> on iop32x/n2100 with GCC 7.2 and binutils 2.29.1 - early boot hangs silently
>>> and I cannot get earlyprintk to work. Compiling with GCC 6.4.0 it's OK.
>>
>> I didn't find the time for GCC 7.2 testing.
>> Yet I have earlyprintk working on my platforms, you need :
>>   - on kernel command line for ttyS0 in my case :
>>     earlycon=early_pxa,mmio,0x40100000
> 
> It dies already during decompression so earlycon does not help much.
> 
> This seems to be simpler to debug/reproduce using busybox. Compiling
> just busybox with GCC 7.2 and march=armv5te/mtune=xscale already
> produces failing xz decompression:
> 

Does it fail too when compiled with gcc 7.2 and with march=armv5t and/or 
march=armv4t ?

> root at thecus-n2100:~$ echo foo > foo.txt
> root at thecus-n2100:~$ xz foo.txt
> root at thecus-n2100:~$ ./busybox.gcc-7.2 xz -d foo.txt.xz
> xz: corrupted data
> root at thecus-n2100:~$ ./busybox.gcc-6.4 xz -d foo.txt.xz
> root at thecus-n2100:~$ cat foo.txt
> foo
> 
> gzip is no better:
> 
> root at thecus-n2100:~$ gzip foo.txt
> root at thecus-n2100:~$ ./busybox.gcc-7.2 gzip -d foo.txt.gz
> gzip: crc error
> root at thecus-n2100:~$ ./busybox.gcc-6.4 gzip -d foo.txt.gz
> root at thecus-n2100:~$ cat foo.txt
> foo
> 

Is it really compiled with armv5te ("readelf -n -A")? I've just found my 
old gcc 6.3 compiled some code with a default armv4t.

Petr