[OE-core] Backport gcc7 fixes for armv5e [ARM] PR 82445

[Andrea Adami]

On Wed, Nov 8, 2017 at 12:30 AM, Andre McCurdy <armccurdy at gmail.com> wrote:
> On Tue, Nov 7, 2017 at 3:00 PM, Andrea Adami <andrea.adami at gmail.com> wrote:
>> On Fri, Nov 3, 2017 at 4:10 PM, akuster808 <akuster808 at gmail.com> wrote:
>>> On 11/02/2017 01:46 AM, Andrea Adami wrote:
>>>>
>>>> the gcc7 shipped with rocko produces unbootable kernels on armv5e [1].
>>>> Bug was fixed recently, apparently in revision 253892 [2]
>>> If you have  a test case ie qemu settings, I can open a bug and handle
>>> it that way too
>>>
>>
>> Armin,
>>
>> once I saw the kernel was not booting on real device I wondered about
>> gcc and did a build for qemuarm/arm926js.
>> This one was booting fine on qemu.
>>
>> I then beated OE's qemu to run for my spitz device (spitz is supported
>> by qemu but lacks some variables needed by the script) and with my
>> surprise it was booting...
>>
>> So no, qemu is not a valid testbench for this specific issue :)
>
> Googling for "qemu arm alignment faults" brings up a few links which
> suggest that to be true - qemu doesn't seem to be strict about
> emulating ARM alignment faults. The links are a little old though, so
> maybe newer qemu versions can configured to be stricter.
>

I have not read the sources but maybe qemu decompresses itself the
kernel image. No idea.
On real HW the XZ decompressor fails to decompress misaligned kernels,
that's a fact.

>   https://stackoverflow.com/questions/19990756/aligment-faults-ignored-on-armv5te-in-qemu
>   https://patchwork.ozlabs.org/patch/550535/

Note a second oddity: at the end of the above link about bug id=82445 you read:

Fixed on trunk gcc-6 & gcc-7

How that? gcc6 produced booting kernels.

Cheers
Andrea