All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tony Lindgren <tony@atomide.com>
To: Russell King - ARM Linux <linux@armlinux.org.uk>
Cc: linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org
Subject: Re: Build failure with verify size in next-20171102
Date: Thu, 2 Nov 2017 16:43:09 -0700	[thread overview]
Message-ID: <20171102234309.GE28152@atomide.com> (raw)
In-Reply-To: <20171102232038.GA28231@n2100.armlinux.org.uk>

* Russell King - ARM Linux <linux@armlinux.org.uk> [171102 23:22]:
> On Thu, Nov 02, 2017 at 12:30:27PM -0700, Tony Lindgren wrote:
> > Hi Russeell,
> > 
> > I think you're already aware of the build failure caused by commit
> > 078c0927485e ("ARM: verify size of zImage"), but here's info just
> > in case.
> > 
> > arm-unknown-linux-musleabi-ld.bfd: error: zImage file size is incorrect
> > make[2]: *** [arch/arm/boot/compressed/Makefile:185: arch/arm/boot/compressed/vmlinux] Error 1
> > make[1]: *** [arch/arm/boot/Makefile:64: arch/arm/boot/compressed/vmlinux] Error 2
> > make: *** [arch/arm/Makefile:335: zImage] Error 2
> > 
> > Other than that I was surprised that next actually booted for me
> > after a few week break with Linux next! :)
> 
> It would be nice if people can investigate why that happens - I'm
> completely unable to reproduce it locally, even if I link using 
> the same vmlinux.lds file and the objects from someone who sees the
> failure.
> 
> There's some binutils version specific stuff that's going on here.
> 
> What I have in my current for-next, which I'm intending to push,
> is all the same patches except the patch that introduces the above
> check is subsituted by a patch that produces an extra _edata_real
> symbol.  This _should_ match _edata.  So, if you hit this failure,
> try either my current for-next branch or tomorrow's linux-next, and
> run arm-linux-nm on arch/arm/boot/compressed/vmlinux and check the
> addresses given for _edata and _edata_real.

OK thanks reverting 078c0927485e and applying dad4675388fc ("ARM:
add debug ".edata_real" symbol") from your for-next branch builds
and boots for me.

> Theory says they should be identical, but the failure of that assert
> could only happen if "." inside the output section was different from
> _edata assigned outside.  _edata_real is now the address of "." inside
> the output section.

With 078c0927485e reverted and dad4675388fc applied they are
identical for me:

$ ${armcompiler}nm arch/arm/boot/compressed/vmlinux | grep _edata
00421960 D _edata
00421960 D _edata_real

Let me know if you want me to run some test with the failing
commit also.

Regards,

Tony

WARNING: multiple messages have this Message-ID (diff)
From: tony@atomide.com (Tony Lindgren)
To: linux-arm-kernel@lists.infradead.org
Subject: Build failure with verify size in next-20171102
Date: Thu, 2 Nov 2017 16:43:09 -0700	[thread overview]
Message-ID: <20171102234309.GE28152@atomide.com> (raw)
In-Reply-To: <20171102232038.GA28231@n2100.armlinux.org.uk>

* Russell King - ARM Linux <linux@armlinux.org.uk> [171102 23:22]:
> On Thu, Nov 02, 2017 at 12:30:27PM -0700, Tony Lindgren wrote:
> > Hi Russeell,
> > 
> > I think you're already aware of the build failure caused by commit
> > 078c0927485e ("ARM: verify size of zImage"), but here's info just
> > in case.
> > 
> > arm-unknown-linux-musleabi-ld.bfd: error: zImage file size is incorrect
> > make[2]: *** [arch/arm/boot/compressed/Makefile:185: arch/arm/boot/compressed/vmlinux] Error 1
> > make[1]: *** [arch/arm/boot/Makefile:64: arch/arm/boot/compressed/vmlinux] Error 2
> > make: *** [arch/arm/Makefile:335: zImage] Error 2
> > 
> > Other than that I was surprised that next actually booted for me
> > after a few week break with Linux next! :)
> 
> It would be nice if people can investigate why that happens - I'm
> completely unable to reproduce it locally, even if I link using 
> the same vmlinux.lds file and the objects from someone who sees the
> failure.
> 
> There's some binutils version specific stuff that's going on here.
> 
> What I have in my current for-next, which I'm intending to push,
> is all the same patches except the patch that introduces the above
> check is subsituted by a patch that produces an extra _edata_real
> symbol.  This _should_ match _edata.  So, if you hit this failure,
> try either my current for-next branch or tomorrow's linux-next, and
> run arm-linux-nm on arch/arm/boot/compressed/vmlinux and check the
> addresses given for _edata and _edata_real.

OK thanks reverting 078c0927485e and applying dad4675388fc ("ARM:
add debug ".edata_real" symbol") from your for-next branch builds
and boots for me.

> Theory says they should be identical, but the failure of that assert
> could only happen if "." inside the output section was different from
> _edata assigned outside.  _edata_real is now the address of "." inside
> the output section.

With 078c0927485e reverted and dad4675388fc applied they are
identical for me:

$ ${armcompiler}nm arch/arm/boot/compressed/vmlinux | grep _edata
00421960 D _edata
00421960 D _edata_real

Let me know if you want me to run some test with the failing
commit also.

Regards,

Tony

  reply	other threads:[~2017-11-02 23:43 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-02 19:30 Build failure with verify size in next-20171102 Tony Lindgren
2017-11-02 19:30 ` Tony Lindgren
2017-11-02 23:20 ` Russell King - ARM Linux
2017-11-02 23:20   ` Russell King - ARM Linux
2017-11-02 23:43   ` Tony Lindgren [this message]
2017-11-02 23:43     ` Tony Lindgren
2017-11-03  0:04     ` Russell King - ARM Linux
2017-11-03  0:04       ` Russell King - ARM Linux
2017-11-03  0:14       ` Russell King - ARM Linux
2017-11-03  0:14         ` Russell King - ARM Linux
2017-11-03  8:22         ` Ard Biesheuvel
2017-11-03  8:22           ` Ard Biesheuvel
2017-11-03  9:12           ` Russell King - ARM Linux
2017-11-03  9:12             ` Russell King - ARM Linux

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=20171102234309.GE28152@atomide.com \
    --to=tony@atomide.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.