linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: will.deacon@arm.com (Will Deacon)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCHv3 3/4] arm64: Update the Image header
Date: Fri, 20 Jun 2014 09:55:43 +0100	[thread overview]
Message-ID: <20140620085543.GH25104@arm.com> (raw)
In-Reply-To: <1403174963-10730-4-git-send-email-mark.rutland@arm.com>

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.

I guess the compiler doesn't allocate (data & 0xff) into a w register?

Will

  reply	other threads:[~2014-06-20  8:55 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-19 10:49 [PATCHv3 0/4] arm64: simplify restrictions on bootloaders Mark Rutland
2014-06-19 10:49 ` [PATCHv3 1/4] arm64: head.S: remove unnecessary function alignment Mark Rutland
2014-06-19 10:49 ` [PATCHv3 2/4] arm64: place initial page tables above the kernel Mark Rutland
2014-06-19 10:49 ` [PATCHv3 3/4] arm64: Update the Image header Mark Rutland
2014-06-20  8:55   ` Will Deacon [this message]
2014-06-20 10:32     ` Mark Rutland
2014-06-20 17:03   ` Geoff Levand
2014-06-24 13:49     ` Mark Rutland
2014-06-19 10:49 ` [PATCHv3 4/4] arm64: Enable TEXT_OFFSET fuzzing Mark Rutland
2014-06-20  8:50   ` Will Deacon
2014-06-20 10:35     ` Mark Rutland
2014-06-20  8:56 ` [PATCHv3 0/4] arm64: simplify restrictions on bootloaders Will Deacon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140620085543.GH25104@arm.com \
    --to=will.deacon@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).