On Mon, Oct 30, 2017 at 03:35:38PM +0000, Ard Biesheuvel wrote: > Well, that is disappointing. This means the ASSERT() does not work > reliably, and we're back to using a bunch of shell scripts to check > whether _edata appears at the end of the image.
That didn't work too well here. While it did correctly detect some instances: zImage size (8008200) disagrees with linked size (8008192) it also misdetected others: zImage size (13348808) disagrees with linked size (-928003328) It seems to suggest that _magic_end - _magic_start = 0xc8afcb00. zImage size is 0xcbafc8. That points at the addresses output by "nm" being dependent on the endian-ness of the image, which to me seems utterly insane. I wouldn't be surprised if that is toolchain version dependent as well. IMHO, our toolchain is a mess! -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up According to speedtest.net: 8.21Mbps down 510kbps up
