[PATCH] ARM: add a private asm/unaligned.h

[Russell King - ARM Linux]

On Mon, Oct 30, 2017 at 04:38:17PM +0000, Russell King - ARM Linux wrote:
> On Mon, Oct 30, 2017 at 05:24:34PM +0100, Gregory CLEMENT wrote:
> > Hi Russell King,
> >  
> > Here you will find all the objects included the vmlinux:
> > 
> > http://free-electrons.com/~gregory/pub/compressed.tgz
> 
> Thanks.  Unfortunately, nothing stands out, but I do see a difference
> between the output of your linker from mine.
> 
> Yours:
> 
> Idx Name          Size      VMA       LMA       File off  Algn
>   0 .text         00005ef8  00000000  00000000  00010000  2**5
>                   CONTENTS, ALLOC, LOAD, READONLY, CODE
> 
> Mine:
> 
> Idx Name          Size      VMA       LMA       File off  Algn
>   0 .text         00005f00  00000000  00000000  00010000  2**5
>                   CONTENTS, ALLOC, LOAD, READONLY, CODE
> 
> That has the effect of moving the addresses of the following
> sections in your vmlinux down by 8 bytes.  However, I don't think
> that's the cause of this - but it does hint at something being
> different in binutils in the way sections are processed in the
> linker.
> 
> Please add to your linker script after the assignment of _edata:
> 
>   .image_end (NOLOAD) : {
>     _edata_foo = .;
>   }
> 
> relink the decompressor, and see what value _edata_foo ends up with
> compared to _edata?  They should be the same, but I suspect using
> your linker, they will be different.
> 
> Also try adding
>     BYTE(0);
> 
> after the _edata_foo assignment as a separate test, and see whether
> that makes any difference - with that you should end up with the
> .image_end section in the output image.

Gregory sent me has new url... for _both_ changes, which gives me:

$ arm-linux-nm vmlinux |grep _edata
00491160 D _edata
00491160 D _edata_foo

So there's no reason that ASSERT() should be failing!  However, as I
don't have the intermediate step, I can't say whether the addition
of the BYTE() affected it in some way - sorry, but I asked for _both_
to be tested above because I wanted to speed up the process, and
clearly that's backfired.

Given how close we potentially are to 4.14, I don't think we're going
to get to the bottom of this to make 4.14.  I'd want to get this
sorted by Wednesday so linux-next (which is resuming this evening)
can grab a copy of my tree with it in, and we have another day to
sort out any remaining issues, but I'm basically out of time to do
anything further with this as of now.

So, 4.14 will likely be released without any of this being fixed.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up