| Submitter | jimdigriz |
|---|---|
| Date | 2010-01-20 08:01:07 |
| Message ID | <vs6k27-7b2.ln1@chipmunk.wormnet.eu> |
| Download | mbox | patch |
| Permalink | /patch/861/ |
| State | Accepted |
| Delegated to: | Ralf Baechle |
| Headers | show |
Comments
Hi, Ralf This patch is a bugfix, which is necessary for the users who are using dash(or the other SHELLs not compatible with bash). without it, they will get a broken compressed kernel image(with wrong load address). Could you please queue it for 2.6.34 and also 2.6.33? Thanks & Regards, Wu Zhangjin On Wed, 2010-01-20 at 20:50 +0000, Alexander Clouter wrote: > Counter to the documentation for the dash shell, it seems that on my > x86_64 filth under Debian only does 32bit math. As I have configured my > lapdog to use 'dash' for non-interactive tasks I run into problems when > compiling a compressed kernel. > > I play with the AR7 platform, so VMLINUX_LOAD_ADDRESS is > 0xffffffff94100000, and for an example 4MiB kernel > VMLINUZ_LOAD_ADDRESS is made out to be: > ---- > alex@berk:~$ bash -c 'printf "%x\n" $((0xffffffff94100000 + 0x400000))' > ffffffff94500000 > alex@berk:~$ dash -c 'printf "%x\n" $((0xffffffff94100000 + 0x400000))' > 80000000003fffff > ---- > > The former is obviously correct whilst the later breaks things royally. > > Fortunately working with only the lower 32bit's works for both bash and > dash: > ---- > $ bash -c 'printf "%x\n" $((0x94100000 + 0x400000))' > 94500000 > $ dash -c 'printf "%x\n" $((0x94100000 + 0x400000))' > 94500000 > ---- > > So, we can split the original 64bit string to two parts, and only > calculate the low 32bit part, which is big enough (1GiB kernel sizes > anyone?) for a normal Linux kernel image file, now, we calculate the > VMLINUZ_LOAD_ADDRESS like this: > > 1. if present, append top 32bit of VMLINUX_LOAD_ADDRESS" as a prefix > 2. get the sum of the low 32bit of VMLINUX_LOAD_ADDRESS + VMLINUX_SIZE > > This patch fixes vmlinuz kernel builds on systems where only a > 32bit-only math shell is available. > > Patch Changelog: > Version 2 > - simplified method by using 'expr' for 'substr' and making it work > with dash once again > Version 1 > - Revert the removals of '-n "$(VMLINUX_SIZE)"' to avoid the error > of "make clean" > - Consider more cases of the VMLINUX_LOAD_ADDRESS > Version 0 > - initial release > > Signed-off-by: Alexander Clouter <alex@digriz.org.uk> > Acked-by: Wu Zhangjin <wuzhangjin@gmail.com> > --- > arch/mips/boot/compressed/Makefile | 7 +++++-- > 1 files changed, 5 insertions(+), 2 deletions(-) > > diff --git a/arch/mips/boot/compressed/Makefile b/arch/mips/boot/compressed/Makefile > index 671d344..ab78095 100644 > --- a/arch/mips/boot/compressed/Makefile > +++ b/arch/mips/boot/compressed/Makefile > @@ -14,8 +14,11 @@ > > # compressed kernel load addr: VMLINUZ_LOAD_ADDRESS > VMLINUX_LOAD_ADDRESS + VMLINUX_SIZE > VMLINUX_SIZE := $(shell wc -c $(objtree)/$(KBUILD_IMAGE) 2>/dev/null | cut -d' ' -f1) > -VMLINUX_SIZE := $(shell [ -n "$(VMLINUX_SIZE)" ] && echo $$(($(VMLINUX_SIZE) + (65536 - $(VMLINUX_SIZE) % 65536)))) > -VMLINUZ_LOAD_ADDRESS := 0x$(shell [ -n "$(VMLINUX_SIZE)" ] && printf %x $$(($(VMLINUX_LOAD_ADDRESS) + $(VMLINUX_SIZE)))) > +VMLINUX_SIZE := $(shell [ -n "$(VMLINUX_SIZE)" ] && echo -n $$(($(VMLINUX_SIZE) + (65536 - $(VMLINUX_SIZE) % 65536)))) > +# VMLINUZ_LOAD_ADDRESS = concat "high32 of VMLINUX_LOAD_ADDRESS" and "(low32 of VMLINUX_LOAD_ADDRESS) + VMLINUX_SIZE" > +HIGH32 := $(shell A=$(VMLINUX_LOAD_ADDRESS); [ $${\#A} -gt 10 ] && expr substr "$(VMLINUX_LOAD_ADDRESS)" 3 $$(($${\#A} - 10))) > +LOW32 := $(shell [ -n "$(HIGH32)" ] && A=11 || A=3; expr substr "$(VMLINUX_LOAD_ADDRESS)" $${A} 8) > +VMLINUZ_LOAD_ADDRESS := 0x$(shell [ -n "$(VMLINUX_SIZE)" -a -n "$(LOW32)" ] && printf "$(HIGH32)%08x" $$(($(VMLINUX_SIZE) + 0x$(LOW32)))) > > # set the default size of the mallocing area for decompressing > BOOT_HEAP_SIZE := 0x400000
On Wed, Jan 20, 2010 at 08:50:07PM +0000, Alexander Clouter wrote: > Counter to the documentation for the dash shell, it seems that on my > x86_64 filth under Debian only does 32bit math. As I have configured my POSIX apparently specifies at least "long" type arithmetic for shells, so if your dash indeed is a 64-bit binary it's in violation of POSIX. What does file $(which $SHELL) say? The dash binary on my Fedora 12 i386 seems to perform 64-bit arithmetic. Ralf
Hi, * Ralf Baechle <ralf@linux-mips.org> [2010-01-22 15:52:56+0100]: > > On Wed, Jan 20, 2010 at 08:50:07PM +0000, Alexander Clouter wrote: > > > Counter to the documentation for the dash shell, it seems that on my > > x86_64 filth under Debian only does 32bit math. As I have configured my > > POSIX apparently specifies at least "long" type arithmetic for shells, so > if your dash indeed is a 64-bit binary it's in violation of POSIX. > /me points to the 'Counter to the documentation for the dash shell...' he put in his description... > What does > > file $(which $SHELL) > > say? > Well, 'bash' (x86-64) as thats my *interactive* shell, I use dash for the non-interactive stuff. > The dash binary on my Fedora 12 i386 seems to perform 64-bit arithmetic. > ...does it really matter, we still are leaving all the 32bit users out there in the lurch? When I get around to looking at the problem further I'll report it to the Debian folk...meanwhile, builds on 32bit math only shells is broken for vmlinuz regardless of my borkened shell :) Cheers
On Fri, 2010-01-22 at 15:52 +0100, Ralf Baechle wrote: > On Wed, Jan 20, 2010 at 08:50:07PM +0000, Alexander Clouter wrote: > > > Counter to the documentation for the dash shell, it seems that on my > > x86_64 filth under Debian only does 32bit math. As I have configured my > > POSIX apparently specifies at least "long" type arithmetic for shells, so > if your dash indeed is a 64-bit binary it's in violation of POSIX. What > does > > file $(which $SHELL) > > say? > > The dash binary on my Fedora 12 i386 seems to perform 64-bit arithmetic. > Hi, Ralf on my yeeloong laptop, with dash(0.5.5.1-3) in o32 ABI, it also can only execute 32-bit numbers, but on my thinkpad SL400(i686, dash version is 0.5.5.1-2), it works well with 64-bit arithmetic. So, it means dash not always works normally, perhaps there is a bug there, or the bug only exists on MIPS machines? Best Regards, Wu Zhangjin
On Sat, Jan 23, 2010 at 07:56:16PM +0800, Wu Zhangjin wrote: > From: Wu Zhangjin <wuzhangjin@gmail.com> > Date: Sat, 23 Jan 2010 19:56:16 +0800 > To: Ralf Baechle <ralf@linux-mips.org> > Cc: Alexander Clouter <alex@digriz.org.uk>, linux-mips@linux-mips.org > Subject: Re: [PATCHv2] MIPS: fix vmlinuz build for 32bit-only math shells > Content-Type: text/plain; charset="UTF-8" > > On Fri, 2010-01-22 at 15:52 +0100, Ralf Baechle wrote: > > On Wed, Jan 20, 2010 at 08:50:07PM +0000, Alexander Clouter wrote: > > > > > Counter to the documentation for the dash shell, it seems that on my > > > x86_64 filth under Debian only does 32bit math. As I have configured my > > > > POSIX apparently specifies at least "long" type arithmetic for shells, so > > if your dash indeed is a 64-bit binary it's in violation of POSIX. What > > does > > > > file $(which $SHELL) > > > > say? > > > > The dash binary on my Fedora 12 i386 seems to perform 64-bit arithmetic. > > > > Hi, Ralf > > on my yeeloong laptop, with dash(0.5.5.1-3) in o32 ABI, it also can only > execute 32-bit numbers, but on my thinkpad SL400(i686, dash version is > 0.5.5.1-2), it works well with 64-bit arithmetic. > > So, it means dash not always works normally, perhaps there is a bug > there, or the bug only exists on MIPS machines? Well, I was wondering if the dash being used by Alexander is simply defect. However in the end that doesn't matter; we try to restrict the build environment to just a standard POSIX environment - or at least as close as possible and that means we can only expect $((<expression)) to perform 32-bit arithmetic. I've applied the patch for now but this is ugly. I was even considering if a small host C program that does the math is the lesser evil. That said, applied. Thanks folks! Ralf
Patch
diff --git a/arch/mips/boot/compressed/Makefile b/arch/mips/boot/compressed/Makefile index 671d344..ab78095 100644 --- a/arch/mips/boot/compressed/Makefile +++ b/arch/mips/boot/compressed/Makefile @@ -14,8 +14,11 @@ # compressed kernel load addr: VMLINUZ_LOAD_ADDRESS > VMLINUX_LOAD_ADDRESS + VMLINUX_SIZE VMLINUX_SIZE := $(shell wc -c $(objtree)/$(KBUILD_IMAGE) 2>/dev/null | cut -d' ' -f1) -VMLINUX_SIZE := $(shell [ -n "$(VMLINUX_SIZE)" ] && echo $$(($(VMLINUX_SIZE) + (65536 - $(VMLINUX_SIZE) % 65536)))) -VMLINUZ_LOAD_ADDRESS := 0x$(shell [ -n "$(VMLINUX_SIZE)" ] && printf %x $$(($(VMLINUX_LOAD_ADDRESS) + $(VMLINUX_SIZE)))) +VMLINUX_SIZE := $(shell [ -n "$(VMLINUX_SIZE)" ] && echo -n $$(($(VMLINUX_SIZE) + (65536 - $(VMLINUX_SIZE) % 65536)))) +# VMLINUZ_LOAD_ADDRESS = concat "high32 of VMLINUX_LOAD_ADDRESS" and "(low32 of VMLINUX_LOAD_ADDRESS) + VMLINUX_SIZE" +HIGH32 := $(shell A=$(VMLINUX_LOAD_ADDRESS); [ $${\#A} -gt 10 ] && expr substr "$(VMLINUX_LOAD_ADDRESS)" 3 $$(($${\#A} - 10))) +LOW32 := $(shell [ -n "$(HIGH32)" ] && A=11 || A=3; expr substr "$(VMLINUX_LOAD_ADDRESS)" $${A} 8) +VMLINUZ_LOAD_ADDRESS := 0x$(shell [ -n "$(VMLINUX_SIZE)" -a -n "$(LOW32)" ] && printf "$(HIGH32)%08x" $$(($(VMLINUX_SIZE) + 0x$(LOW32)))) # set the default size of the mallocing area for decompressing BOOT_HEAP_SIZE := 0x400000
Counter to the documentation for the dash shell, it seems that on my x86_64 filth under Debian only does 32bit math. As I have configured my lapdog to use 'dash' for non-interactive tasks I run into problems when compiling a compressed kernel. I play with the AR7 platform, so VMLINUX_LOAD_ADDRESS is 0xffffffff94100000, and for an example 4MiB kernel VMLINUZ_LOAD_ADDRESS is made out to be: ---- alex@berk:~$ bash -c 'printf "%x\n" $((0xffffffff94100000 + 0x400000))' ffffffff94500000 alex@berk:~$ dash -c 'printf "%x\n" $((0xffffffff94100000 + 0x400000))' 80000000003fffff ---- The former is obviously correct whilst the later breaks things royally. Fortunately working with only the lower 32bit's works for both bash and dash: ---- $ bash -c 'printf "%x\n" $((0x94100000 + 0x400000))' 94500000 $ dash -c 'printf "%x\n" $((0x94100000 + 0x400000))' 94500000 ---- So, we can split the original 64bit string to two parts, and only calculate the low 32bit part, which is big enough (1GiB kernel sizes anyone?) for a normal Linux kernel image file, now, we calculate the VMLINUZ_LOAD_ADDRESS like this: 1. if present, append top 32bit of VMLINUX_LOAD_ADDRESS" as a prefix 2. get the sum of the low 32bit of VMLINUX_LOAD_ADDRESS + VMLINUX_SIZE This patch fixes vmlinuz kernel builds on systems where only a 32bit-only math shell is available. Patch Changelog: Version 2 - simplified method by using 'expr' for 'substr' and making it work with dash once again Version 1 - Revert the removals of '-n "$(VMLINUX_SIZE)"' to avoid the error of "make clean" - Consider more cases of the VMLINUX_LOAD_ADDRESS Version 0 - initial release Signed-off-by: Alexander Clouter <alex@digriz.org.uk> Acked-by: Wu Zhangjin <wuzhangjin@gmail.com> --- arch/mips/boot/compressed/Makefile | 7 +++++-- 1 files changed, 5 insertions(+), 2 deletions(-)