Re: [PATCH 2/2] ARM: read kernel size from zImage

From: Russell King <rmk@armlinux.org.uk>
To: Simon Horman <horms@verge.net.au>,
	Daniel Kiper <daniel.kiper@oracle.com>
Cc: kexec@lists.infradead.org
Subject: Re: [PATCH 2/2] ARM: read kernel size from zImage
Date: Wed, 1 Nov 2017 10:56:36 +0000	[thread overview]
Message-ID: <20171101105636.GG5019@flint.armlinux.org.uk> (raw)
In-Reply-To: <20171101081036.57ahx2bymugl5s37@verge.net.au>

On Wed, Nov 01, 2017 at 09:10:36AM +0100, Simon Horman wrote:
> On Mon, Oct 23, 2017 at 11:08:34AM +0100, Russell King wrote:
> > Read the new extension data which tells the boot agent about the
> > requirements for booting the kernel image, such as how much RAM
> > will be consumed by the kernel through decompression and booting.
> > This is necessary to control the placement of the DTB and
> > compressed RAM disk to avoid these objects being corrupted.
> > 
> > Tested-by: Tony Lindgren <tony@atomide.com>
> > Signed-off-by: Russell King <rmk@armlinux.org.uk>
> 
> Thanks, applied.

Thanks, since I rebased my tree, I've realised that wasn't quite the
patch I intended, but it'll do for now.

Building the latest tree gives me a new warning:

gcc -g -O2 -fno-strict-aliasing -Wall -Wstrict-prototypes -I./include -I./util_lib/include -Iinclude/ -I./kexec/libfdt -D_FILE_OFFSET_BITS=64 -I./kexec/arch/arm/include  -c -MD -o kexec/kexec.o kexec/kexec.c
kexec/kexec.c: In function ■print_crashkernel_region_size■:
kexec/kexec.c:1232:9: warning: format ■%lu■ expects argument of type ■long unsigned int■, but argument 2 has type ■uint64_t {aka long long unsigned int}■ [-Wformat=]
  printf("%lu\n", (start != end) ? (end - start + 1) : 0UL);
         ^

caused by:

commit 76b31203222a9833f424e98a134603c2f840c82b
Author: Daniel Kiper <daniel.kiper@oracle.com>
Date:   Fri Feb 17 16:47:25 2017 -0600

    kexec: Add option to get crash kernel region size

On 32-bit architectures, "%lu" expects an unsigned long, but uint64_t is
an unsigned long long.  On 64-bit architectures, "%lu" also expects an
unsigned long, but uint64_t is unsigned long, so there's no warning.

The problem for ARM here is that a 64-bit value is passed as an
even-odd register pair, so for the above printf, that would be r2, r3.
However, "%lu" will expect the value in the first register following
the format pointer, that being r1.  So we end up printing garbage here.

Either we use "%llu" and cast the value to an unsigned long long
(needlessly widening on 64-bit arches), or "%lu" and cast to unsigned
long (truncating) or we need a definition of the format to be used for
uint64_t types (tends to be messy.)

-- 
Russell King

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec