[PATCHv3 3/4] arm64: Update the Image header
Mark Rutland
mark.rutland at arm.com
Fri Jun 20 03:32:07 PDT 2014
On Fri, Jun 20, 2014 at 09:55:43AM +0100, Will Deacon wrote:
> On Thu, Jun 19, 2014 at 11:49:22AM +0100, Mark Rutland wrote:
> > Currently the kernel Image is stripped of everything past the initial
> > stack, and at runtime the memory is initialised and used by the kernel.
> > This makes the effective minimum memory footprint of the kernel larger
> > than the size of the loaded binary, though bootloaders have no mechanism
> > to identify how large this minimum memory footprint is. This makes it
> > difficult to choose safe locations to place both the kernel and other
> > binaries required at boot (DTB, initrd, etc), such that the kernel won't
> > clobber said binaries or other reserved memory during initialisation.
>
> [...]
>
> > +/*
> > + * There aren't any ELF relocations we can use to endian-swap values known only
> > + * at link time (e.g. the subtraction of two symbol addresses), so we must get
> > + * the linker to endian-swap certain values before emitting them.
> > + */
> > +#ifdef CONFIG_CPU_BIG_ENDIAN
> > +#define DATA_LE64(data) \
> > + ((((data) & 0x00000000000000ff) << 56) | \
> > + (((data) & 0x000000000000ff00) << 40) | \
>
> Are you sure that these shifts are valid without a UL prefix on the first
> constant operand? I don't think the leading zeroes promote the mask to a
> 64-bit type, so you end up shifting greater than the width of the type.
A key point to bear in mind is that this is in ld, not gas or gcc, which
is why I needed a new macro in the first place. See the error on #ifndef
LINKER_SCRIPT at the top of the file.
As far as I can tell these are valid within ld. The GNU ld documentation
says expressions should be evaluated as 64-bit values (given that
aarch64 is 64-bit) [1].
The kernel header looks correct when inspected with a hex editor, for
both LE and BE.
> I guess the compiler doesn't allocate (data & 0xff) into a w register?
I would guess it wouldn't allocate anything given it is not involved :)
Mark.
[1] https://sourceware.org/binutils/docs/ld/Expressions.html#Expressions
More information about the linux-arm-kernel
mailing list