Re: GCC 5 snapshots produce broken kernel for powerpc-e500v2-linux-gnuspe?

[Arseny Solokha <asolokha at gmx dot com>]

Makrus, Andrew, thanks for your suggestions.


>> On Sep 9, 2014, at 2:57 AM, Markus Trippelsdorf <markus@trippelsdorf.de> wrote:
>> 
>>> On 2014.09.09 at 17:35 +0800, Arseny Solokha wrote:
>>> Hello,
>>> 
>>> I've recently faced an issue I'm afraid I currently unable to debug. When
>>> building an arbitrary version of Linux kernel for powerpc-e500v2-linux-gnuspe
>>> target, it seems gcc prior to 5 produces a good image which boots just fine, and
>>> current gcc 5 snapshots (4.10.0-alpha20140810 for example) produce an image
>>> which hangs just after U-Boot hands over to the kernel.
>>> 
>>> This behavior is well reproducible on real hardware as well as under qemu. I've
>>> prepared a minimal kernel config which is dysfunctional as is but still enough
>>> to demonstrate the problem in qemu. I believe the exact Linux version number
>>> doesn't actually matter here, but see the attachment for details.
>>> 
>>> Compare the output produced by u-boot and this minified kernel build using
>>> gcc 4.9.1 and 4.10.0-alpha20140810 snapshot.
>>> 
>>> I now have completely no idea what to do next to find a cause of (1) gcc 5
>>> snapshots producing unbootable kernel, 
>> 
>> gcc trunk also miscompiles x86_64 kernels currently, but I haven't
>> looked deeper yet. 
>> The best way to narrow down the issue is to use git (or svn) bisect to
>> find out which gcc revision causes the miscompile.  Then you can md5sum
>> the kernel object files for the bad revision and for the first good
>> revision and compare the results. After that you can look at the
>> disassembly of the object files, for which md5sum differs, and try to
>> figure out the reason why.

OK, bisect is of course one way to find a culprit revision and then files it
miscompiles. However, one difficulty w/ this approach is that SPE ABI support in
GCC (and probably other places too) is in semi-bitrot state by now, so there is
a preliminary consideration that not every revision could even be buildable. I
don't have any better idea, though.

Regarding the case of missing sections in kernel module built w/ stable GCC
versions after tinkering w/ CFLAGS, what can be the cause? Is it possible that
ld, or as, or kernel linker script is real culprit? Because this started showing
up since 4.8, and the only difference in assembler output I can see between 4.7
and 4.10 is use of isel instructions by the latter even though -misel isn't
appended to kernel CFLAGS by default.


> I have a patch which I need to submit. Maybe by Friday I will do that. It fixes the kernel on arm64 but it is generic c front-end patch. 

So I'll for sure try current trunk next week once again.


Regards.


>> 
>> -- 
>> Markus