[U-Boot] omap4: LDFLAGS=build-id flag generates wrong u-boot.bin

[Nishanth Menon <nm@ti.com>]

Hi,
While generating MeeGo u-boot repository for omap4_panda configuration, 
I ran into a curious issue, I happened to add LDFLAGS=--build-id and it 
ended up generating a 2.5GB u-boot.bin.
digging a little further, I see the linking stage adding --build-id

arm-none-linux-gnueabi-ld --build-id -Bstatic -T u-boot.lds  -Ttext 
0x9ff00000 $UNDEF_SYM arch/arm/cpu/armv7/start.o --start-group 
lib/libgeneric.a lib/lzma/liblzma.a lib/lzo/liblzo.a 
arch/arm/cpu/armv7/libarmv7.a arch/arm/cpu/armv7/omap4/libomap4.a 
arch/arm/lib/libarm.a fs/cramfs/libcramfs.a fs/fat/libfat.a 
fs/fdos/libfdos.a fs/jffs2/libjffs2.a fs/reiserfs/libreiserfs.a 
fs/ext2/libext2fs.a fs/yaffs2/libyaffs2.a fs/ubifs/libubifs.a 
net/libnet.a disk/libdisk.a drivers/bios_emulator/libatibiosemu.a 
drivers/block/libblock.a drivers/dma/libdma.a drivers/fpga/libfpga.a 
drivers/gpio/libgpio.a drivers/hwmon/libhwmon.a drivers/i2c/libi2c.a 
drivers/input/libinput.a drivers/misc/libmisc.a drivers/mmc/libmmc.a 
drivers/mtd/libmtd.a drivers/mtd/nand/libnand.a 
drivers/mtd/onenand/libonenand.a drivers/mtd/ubi/libubi.a 
drivers/mtd/spi/libspi_flash.a drivers/net/libnet.a 
drivers/net/phy/libphy.a drivers/pci/libpci.a drivers/pcmcia/libpcmcia.a 
drivers/power/libpower.a drivers/spi/libspi.a drivers/rtc/librtc.a 
drivers/serial/libserial.a drivers/twserial/libtws.a 
drivers/usb/gadget/libusb_gadget.a drivers/usb/host/libusb_host.a 
drivers/usb/musb/libusb_musb.a drivers/usb/phy/libusb_phy.a 
drivers/video/libvideo.a drivers/watchdog/libwatchdog.a 
common/libcommon.a lib/libfdt/libfdt.a api/libapi.a post/libpost.a 
arch/arm/cpu/armv7/omap-common/libomap-common.a 
board/ti/panda/libpanda.a --end-group 
/home/nmenon/Src/opensource/u-boot/arch/arm/lib/eabi_compat.o -L 
/opt/arm/arm-2010q1/bin/../lib/gcc/arm-none-linux-gnueabi/4.4.1/armv4t 
-lgcc -Map u-boot.map -o u-boot
This results in the following section being added to u-boot

Disassembly of section .note.gnu.build-id:

00000000 <.note.gnu.build-id>:
    0:	00000004 	andeq	r0, r0, r4
    4:	00000014 	andeq	r0, r0, r4, lsl r0
    8:	00000003 	andeq	r0, r0, r3
    c:	00554e47 	subseq	r4, r5, r7, asr #28
   10:	3c3c6218 	lfmcc	f6, 4, [ip], #-96	; 0xffffffa0
   14:	015620ef 	cmpeq	r6, pc, ror #1
   18:	723aeceb 	eorsvc	lr, sl, #60160	; 0xeb00
   1c:	5eade957 	mcrpl	9, 5, lr, cr13, cr7, {2}
   20:	1cf9a5e7 	cfldr64ne	mvdx10, [r9], #924	; 0x39c

Disassembly of section .text:

9ff00000 <_start>:
9ff00000:	ea000012 	b	9ff00050 <reset>
<snip>

and that explained my 2.5GB as  "arm-none-linux-gnueabi-objcopy 
--gap-fill=0xff -O binary u-boot u-boot.bin" tried to fill up the 0x0 to 
0x9ff00000 with 0xff :)


I am just curious if someone had seen and fixed something like this 
elsewhere..

-- 
Regards,
Nishanth Menon