[U-Boot] [PATCH] Switch from archive libraries to partial linking
NOTE: This does not include the actual patch as it is too large for the mailing list (418 kB).
Before this commit, weak symbols were not overridden by non-weak symbols found in archive libraries when linking with recent versions of binutils. As stated in the System V ABI, "the link editor does not extract archive members to resolve undefined weak symbols".
This commit changes all Makefiles to use partial linking (ld -r) instead of creating library archives, which forces all symbols to participate in linking, allowing non-weak symbols to override weak symbols as intended. This approach is also used by Linux, from which the gmake function cmd_link_o_target (added at the end of config.mk and used in all Makefiles) is inspired.
The name of each former library archive is preserved except for extensions which change from ".a" to ".o". This commit updates references accordingly where needed, in particular in some linker scripts.
This commit reveals board configurations that exclude some module but not all of its dependencies; for example, disabling CMD_NET but not CMD_NFS results in undefined symbols at link time.
Signed-off-by: Sebastien Carlier sebastien.carlier@gmail.com --- Makefile | 118 ++++++++++++++-------------- api/Makefile | 4 +- arch/arm/cpu/arm1136/Makefile | 4 +- arch/arm/cpu/arm1136/mx31/Makefile | 4 +- arch/arm/cpu/arm1136/omap24xx/Makefile | 4 +- arch/arm/cpu/arm1176/Makefile | 4 +- arch/arm/cpu/arm1176/s3c64xx/Makefile | 4 +- arch/arm/cpu/arm1176/tnetv107x/Makefile | 4 +- arch/arm/cpu/arm720t/Makefile | 4 +- arch/arm/cpu/arm720t/lpc2292/Makefile | 4 +- arch/arm/cpu/arm720t/s3c4510b/Makefile | 4 +- arch/arm/cpu/arm920t/Makefile | 4 +- arch/arm/cpu/arm920t/a320/Makefile | 4 +- arch/arm/cpu/arm920t/at91/Makefile | 4 +- arch/arm/cpu/arm920t/at91rm9200/Makefile | 4 +- arch/arm/cpu/arm920t/ep93xx/Makefile | 4 +- arch/arm/cpu/arm920t/imx/Makefile | 4 +- arch/arm/cpu/arm920t/ks8695/Makefile | 4 +- arch/arm/cpu/arm920t/s3c24x0/Makefile | 4 +- arch/arm/cpu/arm925t/Makefile | 4 +- arch/arm/cpu/arm926ejs/Makefile | 4 +- arch/arm/cpu/arm926ejs/at91/Makefile | 4 +- arch/arm/cpu/arm926ejs/davinci/Makefile | 4 +- arch/arm/cpu/arm926ejs/kirkwood/Makefile | 4 +- arch/arm/cpu/arm926ejs/mb86r0x/Makefile | 4 +- arch/arm/cpu/arm926ejs/mx25/Makefile | 4 +- arch/arm/cpu/arm926ejs/mx27/Makefile | 4 +- arch/arm/cpu/arm926ejs/nomadik/Makefile | 4 +- arch/arm/cpu/arm926ejs/omap/Makefile | 4 +- arch/arm/cpu/arm926ejs/orion5x/Makefile | 4 +- arch/arm/cpu/arm926ejs/spear/Makefile | 4 +- arch/arm/cpu/arm926ejs/versatile/Makefile | 4 +- arch/arm/cpu/arm946es/Makefile | 4 +- arch/arm/cpu/arm_intcm/Makefile | 4 +- arch/arm/cpu/armv7/Makefile | 4 +- arch/arm/cpu/armv7/mx5/Makefile | 4 +- arch/arm/cpu/armv7/omap-common/Makefile | 4 +- arch/arm/cpu/armv7/omap3/Makefile | 4 +- arch/arm/cpu/armv7/omap4/Makefile | 4 +- arch/arm/cpu/armv7/s5p-common/Makefile | 4 +- arch/arm/cpu/armv7/s5pc1xx/Makefile | 4 +- arch/arm/cpu/ixp/Makefile | 4 +- arch/arm/cpu/ixp/npe/Makefile | 4 +- arch/arm/cpu/lh7a40x/Makefile | 4 +- arch/arm/cpu/pxa/Makefile | 4 +- arch/arm/cpu/s3c44b0/Makefile | 4 +- arch/arm/cpu/sa1100/Makefile | 4 +- arch/arm/lib/Makefile | 10 +- arch/avr32/cpu/Makefile | 4 +- arch/avr32/cpu/at32ap700x/Makefile | 4 +- arch/avr32/lib/Makefile | 4 +- arch/blackfin/cpu/Makefile | 4 +- arch/blackfin/lib/Makefile | 4 +- arch/i386/cpu/Makefile | 4 +- arch/i386/cpu/sc520/Makefile | 4 +- arch/i386/lib/Makefile | 4 +- arch/m68k/cpu/mcf5227x/Makefile | 4 +- arch/m68k/cpu/mcf523x/Makefile | 4 +- arch/m68k/cpu/mcf52x2/Makefile | 4 +- arch/m68k/cpu/mcf532x/Makefile | 4 +- arch/m68k/cpu/mcf5445x/Makefile | 4 +- arch/m68k/cpu/mcf547x_8x/Makefile | 4 +- arch/m68k/lib/Makefile | 4 +- arch/microblaze/cpu/Makefile | 4 +- arch/microblaze/lib/Makefile | 4 +- arch/mips/cpu/Makefile | 4 +- arch/mips/lib/Makefile | 4 +- arch/nios2/cpu/Makefile | 4 +- arch/nios2/lib/Makefile | 4 +- arch/powerpc/cpu/74xx_7xx/Makefile | 4 +- arch/powerpc/cpu/mpc512x/Makefile | 4 +- arch/powerpc/cpu/mpc5xx/Makefile | 4 +- arch/powerpc/cpu/mpc5xxx/Makefile | 4 +- arch/powerpc/cpu/mpc8220/Makefile | 4 +- arch/powerpc/cpu/mpc824x/Makefile | 4 +- arch/powerpc/cpu/mpc8260/Makefile | 4 +- arch/powerpc/cpu/mpc83xx/Makefile | 4 +- arch/powerpc/cpu/mpc85xx/Makefile | 4 +- arch/powerpc/cpu/mpc86xx/Makefile | 4 +- arch/powerpc/cpu/mpc8xx/Makefile | 4 +- arch/powerpc/cpu/mpc8xxx/Makefile | 4 +- arch/powerpc/cpu/mpc8xxx/ddr/Makefile | 4 +- arch/powerpc/cpu/ppc4xx/Makefile | 4 +- arch/powerpc/lib/Makefile | 4 +- arch/sh/cpu/sh2/Makefile | 4 +- arch/sh/cpu/sh3/Makefile | 4 +- arch/sh/cpu/sh4/Makefile | 4 +- arch/sh/lib/Makefile | 4 +- arch/sparc/cpu/leon2/Makefile | 4 +- arch/sparc/cpu/leon3/Makefile | 4 +- arch/sparc/lib/Makefile | 4 +- board/BuS/EB+MCF-EV123/Makefile | 4 +- board/BuS/eb_cpux9k2/Makefile | 4 +- board/LEOX/elpt860/Makefile | 4 +- board/LaCie/edminiv2/Makefile | 4 +- board/Marvell/db64360/Makefile | 4 +- board/Marvell/db64460/Makefile | 4 +- board/Marvell/guruplug/Makefile | 4 +- board/Marvell/mv88f6281gtw_ge/Makefile | 4 +- board/Marvell/openrd_base/Makefile | 4 +- board/Marvell/rd6281a/Makefile | 4 +- board/Marvell/sheevaplug/Makefile | 4 +- board/RPXClassic/Makefile | 4 +- board/RPXlite/Makefile | 4 +- board/RPXlite_dw/Makefile | 4 +- board/RRvision/Makefile | 4 +- board/a3000/Makefile | 4 +- board/a4m072/Makefile | 4 +- board/actux1/Makefile | 4 +- board/actux1/config.mk | 2 +- board/actux2/Makefile | 4 +- board/actux2/config.mk | 2 +- board/actux3/Makefile | 4 +- board/actux3/config.mk | 2 +- board/actux4/Makefile | 4 +- board/actux4/config.mk | 2 +- board/adder/Makefile | 4 +- board/afeb9260/Makefile | 4 +- board/alaska/Makefile | 4 +- board/altera/nios2-generic/Makefile | 4 +- board/amcc/acadia/Makefile | 4 +- board/amcc/bamboo/Makefile | 4 +- board/amcc/bluestone/Makefile | 4 +- board/amcc/bubinga/Makefile | 4 +- board/amcc/canyonlands/Makefile | 4 +- board/amcc/ebony/Makefile | 4 +- board/amcc/katmai/Makefile | 4 +- board/amcc/kilauea/Makefile | 4 +- board/amcc/luan/Makefile | 4 +- board/amcc/makalu/Makefile | 4 +- board/amcc/ocotea/Makefile | 4 +- board/amcc/redwood/Makefile | 4 +- board/amcc/sequoia/Makefile | 4 +- board/amcc/taihu/Makefile | 4 +- board/amcc/taishan/Makefile | 4 +- board/amcc/walnut/Makefile | 4 +- board/amcc/yosemite/Makefile | 4 +- board/amcc/yucca/Makefile | 4 +- board/amirix/ap1000/Makefile | 4 +- board/apollon/Makefile | 4 +- board/armadillo/Makefile | 4 +- board/armltd/integrator/Makefile | 4 +- board/armltd/versatile/Makefile | 4 +- board/armltd/vexpress/Makefile | 4 +- board/assabet/Makefile | 4 +- board/astro/mcf5373l/Makefile | 4 +- board/atc/Makefile | 4 +- board/atmel/at91cap9adk/Makefile | 4 +- board/atmel/at91rm9200dk/Makefile | 4 +- board/atmel/at91rm9200ek/Makefile | 4 +- board/atmel/at91sam9260ek/Makefile | 4 +- board/atmel/at91sam9261ek/Makefile | 4 +- board/atmel/at91sam9263ek/Makefile | 4 +- board/atmel/at91sam9m10g45ek/Makefile | 4 +- board/atmel/at91sam9rlek/Makefile | 4 +- board/atmel/atngw100/Makefile | 4 +- board/atmel/atstk1000/Makefile | 4 +- board/atum8548/Makefile | 4 +- board/balloon3/Makefile | 4 +- board/barco/Makefile | 4 +- board/bc3450/Makefile | 4 +- board/bct-brettl2/Makefile | 4 +- board/bf518f-ezbrd/Makefile | 4 +- board/bf526-ezbrd/Makefile | 4 +- board/bf527-ad7160-eval/Makefile | 4 +- board/bf527-ezkit/Makefile | 4 +- board/bf527-sdp/Makefile | 4 +- board/bf533-ezkit/Makefile | 4 +- board/bf533-stamp/Makefile | 4 +- board/bf537-minotaur/Makefile | 4 +- board/bf537-pnav/Makefile | 4 +- board/bf537-srv1/Makefile | 4 +- board/bf537-stamp/Makefile | 4 +- board/bf538f-ezkit/Makefile | 4 +- board/bf548-ezkit/Makefile | 4 +- board/bf561-acvilon/Makefile | 4 +- board/bf561-ezkit/Makefile | 4 +- board/blackstamp/Makefile | 4 +- board/blackvme/Makefile | 4 +- board/bmw/Makefile | 4 +- board/c2mon/Makefile | 4 +- board/calao/sbc35_a9g20/Makefile | 4 +- board/calao/tny_a9260/Makefile | 4 +- board/canmb/Makefile | 4 +- board/cerf250/Makefile | 4 +- board/cm-bf527/Makefile | 4 +- board/cm-bf533/Makefile | 4 +- board/cm-bf537e/Makefile | 4 +- board/cm-bf537u/Makefile | 4 +- board/cm-bf548/Makefile | 4 +- board/cm-bf561/Makefile | 4 +- board/cm4008/Makefile | 4 +- board/cm41xx/Makefile | 4 +- board/cm5200/Makefile | 4 +- board/cmc_pu2/Makefile | 4 +- board/cmi/Makefile | 4 +- board/cobra5272/Makefile | 4 +- board/cogent/Makefile | 4 +- board/colibri_pxa270/Makefile | 4 +- board/cpc45/Makefile | 4 +- board/cpu86/Makefile | 4 +- board/cpu87/Makefile | 4 +- board/cradle/Makefile | 4 +- board/cray/L1/Makefile | 4 +- board/csb226/Makefile | 4 +- board/csb272/Makefile | 4 +- board/csb472/Makefile | 4 +- board/csb637/Makefile | 4 +- board/cu824/Makefile | 4 +- board/dave/B2/Makefile | 4 +- board/dave/PPChameleonEVB/Makefile | 4 +- board/davedenx/aria/Makefile | 4 +- board/davedenx/qong/Makefile | 4 +- board/davinci/common/Makefile | 4 +- board/davinci/da8xxevm/Makefile | 4 +- board/davinci/dm355evm/Makefile | 4 +- board/davinci/dm355leopard/Makefile | 4 +- board/davinci/dm365evm/Makefile | 4 +- board/davinci/dm6467evm/Makefile | 4 +- board/davinci/dvevm/Makefile | 4 +- board/davinci/schmoogie/Makefile | 4 +- board/davinci/sffsdr/Makefile | 4 +- board/davinci/sonata/Makefile | 4 +- board/dbau1x00/Makefile | 4 +- board/digsy_mtc/Makefile | 4 +- board/dnp1110/Makefile | 4 +- board/eNET/Makefile | 4 +- board/eXalion/Makefile | 4 +- board/earthlcd/favr-32-ezkit/Makefile | 4 +- board/edb93xx/Makefile | 4 +- board/eltec/bab7xx/Makefile | 4 +- board/eltec/elppc/Makefile | 4 +- board/eltec/mhpc/Makefile | 4 +- board/emk/top5200/Makefile | 4 +- board/emk/top860/Makefile | 4 +- board/ep7312/Makefile | 4 +- board/ep8248/Makefile | 4 +- board/ep8260/Makefile | 4 +- board/ep82xxm/Makefile | 4 +- board/ep88x/Makefile | 4 +- board/eric/Makefile | 4 +- board/esd/adciop/Makefile | 4 +- board/esd/apc405/Makefile | 4 +- board/esd/ar405/Makefile | 4 +- board/esd/ash405/Makefile | 4 +- board/esd/canbt/Makefile | 4 +- board/esd/cms700/Makefile | 4 +- board/esd/cpci2dp/Makefile | 4 +- board/esd/cpci405/Makefile | 4 +- board/esd/cpci5200/Makefile | 4 +- board/esd/cpci750/Makefile | 4 +- board/esd/cpciiser4/Makefile | 4 +- board/esd/dasa_sim/Makefile | 4 +- board/esd/dp405/Makefile | 4 +- board/esd/du405/Makefile | 4 +- board/esd/du440/Makefile | 4 +- board/esd/hh405/Makefile | 4 +- board/esd/hub405/Makefile | 4 +- board/esd/mecp5123/Makefile | 4 +- board/esd/mecp5200/Makefile | 4 +- board/esd/meesc/Makefile | 4 +- board/esd/ocrtc/Makefile | 4 +- board/esd/otc570/Makefile | 4 +- board/esd/pci405/Makefile | 6 +- board/esd/pf5200/Makefile | 4 +- board/esd/plu405/Makefile | 4 +- board/esd/pmc405/Makefile | 4 +- board/esd/pmc405de/Makefile | 4 +- board/esd/pmc440/Makefile | 4 +- board/esd/tasreg/Makefile | 4 +- board/esd/vme8349/Makefile | 4 +- board/esd/voh405/Makefile | 4 +- board/esd/vom405/Makefile | 4 +- board/esd/wuh405/Makefile | 4 +- board/espt/Makefile | 4 +- board/esteem192e/Makefile | 4 +- board/etin/debris/Makefile | 4 +- board/etin/kvme080/Makefile | 4 +- board/etx094/Makefile | 4 +- board/eukrea/cpu9260/Makefile | 4 +- board/eukrea/cpuat91/Makefile | 4 +- board/evb4510/Makefile | 4 +- board/evb64260/Makefile | 4 +- board/fads/Makefile | 4 +- board/faraday/a320evb/Makefile | 4 +- board/flagadm/Makefile | 4 +- board/freescale/common/Makefile | 4 +- board/freescale/corenet_ds/Makefile | 4 +- board/freescale/m5208evbe/Makefile | 4 +- board/freescale/m5208evbe/u-boot.lds | 4 +- board/freescale/m52277evb/Makefile | 4 +- board/freescale/m52277evb/u-boot.spa | 6 +- board/freescale/m5235evb/Makefile | 4 +- board/freescale/m5235evb/u-boot.32 | 4 +- board/freescale/m5249evb/Makefile | 4 +- board/freescale/m5253demo/Makefile | 4 +- board/freescale/m5253evbe/Makefile | 4 +- board/freescale/m5271evb/Makefile | 4 +- board/freescale/m5271evb/u-boot.lds | 2 +- board/freescale/m5272c3/Makefile | 4 +- board/freescale/m5275evb/Makefile | 4 +- board/freescale/m5282evb/Makefile | 4 +- board/freescale/m53017evb/Makefile | 4 +- board/freescale/m53017evb/u-boot.lds | 4 +- board/freescale/m5329evb/Makefile | 4 +- board/freescale/m5373evb/Makefile | 4 +- board/freescale/m54451evb/Makefile | 4 +- board/freescale/m54451evb/u-boot.spa | 6 +- board/freescale/m54455evb/Makefile | 4 +- board/freescale/m547xevb/Makefile | 4 +- board/freescale/m548xevb/Makefile | 4 +- board/freescale/mpc5121ads/Makefile | 4 +- board/freescale/mpc7448hpc2/Makefile | 4 +- board/freescale/mpc8260ads/Makefile | 4 +- board/freescale/mpc8266ads/Makefile | 4 +- board/freescale/mpc8308rdb/Makefile | 4 +- board/freescale/mpc8313erdb/Makefile | 4 +- board/freescale/mpc8315erdb/Makefile | 4 +- board/freescale/mpc8323erdb/Makefile | 4 +- board/freescale/mpc832xemds/Makefile | 4 +- board/freescale/mpc8349emds/Makefile | 4 +- board/freescale/mpc8349itx/Makefile | 4 +- board/freescale/mpc8360emds/Makefile | 4 +- board/freescale/mpc8360erdk/Makefile | 4 +- board/freescale/mpc837xemds/Makefile | 4 +- board/freescale/mpc837xerdb/Makefile | 4 +- board/freescale/mpc8536ds/Makefile | 4 +- board/freescale/mpc8540ads/Makefile | 4 +- board/freescale/mpc8541cds/Makefile | 4 +- board/freescale/mpc8544ds/Makefile | 4 +- board/freescale/mpc8548cds/Makefile | 4 +- board/freescale/mpc8555cds/Makefile | 4 +- board/freescale/mpc8560ads/Makefile | 4 +- board/freescale/mpc8568mds/Makefile | 4 +- board/freescale/mpc8569mds/Makefile | 4 +- board/freescale/mpc8572ds/Makefile | 4 +- board/freescale/mpc8610hpcd/Makefile | 4 +- board/freescale/mpc8641hpcn/Makefile | 4 +- board/freescale/mx31ads/Makefile | 4 +- board/freescale/mx31ads/u-boot.lds | 8 +- board/freescale/mx31pdk/Makefile | 4 +- board/freescale/mx51evk/Makefile | 4 +- board/freescale/p1022ds/Makefile | 4 +- board/freescale/p1_p2_rdb/Makefile | 4 +- board/freescale/p2020ds/Makefile | 4 +- board/funkwerk/vovpn-gw/Makefile | 4 +- board/g2000/Makefile | 4 +- board/gaisler/gr_cpci_ax2000/Makefile | 4 +- board/gaisler/gr_ep2s60/Makefile | 4 +- board/gaisler/gr_xc3s_1500/Makefile | 4 +- board/gaisler/grsim/Makefile | 4 +- board/gaisler/grsim_leon2/Makefile | 4 +- board/galaxy5200/Makefile | 4 +- board/gcplus/Makefile | 4 +- board/gdsys/405ep/Makefile | 4 +- board/gdsys/common/Makefile | 4 +- board/gdsys/dlvision/Makefile | 4 +- board/gdsys/gdppc440etx/Makefile | 4 +- board/gdsys/intip/Makefile | 4 +- board/gdsys/neo/Makefile | 4 +- board/gen860t/Makefile | 4 +- board/genietv/Makefile | 4 +- board/gth2/Makefile | 4 +- board/gw8260/Makefile | 4 +- board/hermes/Makefile | 4 +- board/hidden_dragon/Makefile | 4 +- board/hymod/Makefile | 4 +- board/ibf-dsp561/Makefile | 4 +- board/icecube/Makefile | 4 +- board/icu862/Makefile | 4 +- board/idmr/Makefile | 4 +- board/idmr/u-boot.lds | 2 +- board/ids8247/Makefile | 4 +- board/impa7/Makefile | 4 +- board/imx31_phycore/Makefile | 4 +- board/incaip/Makefile | 4 +- board/inka4x0/Makefile | 4 +- board/innokom/Makefile | 4 +- board/ip04/Makefile | 4 +- board/ip860/Makefile | 4 +- board/ipek01/Makefile | 4 +- board/iphase4539/Makefile | 4 +- board/isee/igep0020/Makefile | 4 +- board/isee/igep0030/Makefile | 4 +- board/ispan/Makefile | 4 +- board/ivm/Makefile | 4 +- board/ixdp425/Makefile | 4 +- board/jornada/Makefile | 4 +- board/jse/Makefile | 4 +- board/jupiter/Makefile | 4 +- board/karo/tx25/Makefile | 4 +- board/kb9202/Makefile | 4 +- board/keymile/km8xx/Makefile | 4 +- board/keymile/km_arm/Makefile | 4 +- board/keymile/kmeter1/Makefile | 4 +- board/keymile/mgcoge/Makefile | 4 +- board/korat/Makefile | 4 +- board/kup/Makefile | 4 +- board/kup/kup4k/Makefile | 4 +- board/kup/kup4x/Makefile | 4 +- board/lantec/Makefile | 4 +- board/lart/Makefile | 4 +- board/linkstation/Makefile | 4 +- board/logicpd/am3517evm/Makefile | 4 +- board/logicpd/imx27lite/Makefile | 4 +- board/logicpd/imx31_litekit/Makefile | 4 +- board/logicpd/zoom1/Makefile | 4 +- board/logicpd/zoom2/Makefile | 4 +- board/lpc2292sodimm/Makefile | 4 +- board/lpd7a40x/Makefile | 4 +- board/lubbock/Makefile | 4 +- board/lwmon/Makefile | 4 +- board/lwmon5/Makefile | 4 +- board/m501sk/Makefile | 4 +- board/manroland/hmi1001/Makefile | 4 +- board/manroland/mucmc52/Makefile | 4 +- board/manroland/uc100/Makefile | 4 +- board/manroland/uc101/Makefile | 4 +- board/matrix_vision/common/Makefile | 4 +- board/matrix_vision/mvbc_p/Makefile | 4 +- board/matrix_vision/mvblm7/Makefile | 4 +- board/matrix_vision/mvsmr/Makefile | 4 +- board/mbx8xx/Makefile | 4 +- board/mcc200/Makefile | 4 +- board/micronas/vct/Makefile | 4 +- board/mimc/mimc200/Makefile | 4 +- board/miromico/hammerhead/Makefile | 4 +- board/ml2/Makefile | 4 +- board/modnet50/Makefile | 4 +- board/mosaixtech/icon/Makefile | 4 +- board/motionpro/Makefile | 4 +- board/mousse/Makefile | 4 +- board/mp2usb/Makefile | 4 +- board/mpc8308_p1m/Makefile | 4 +- board/mpc8540eval/Makefile | 4 +- board/mpl/mip405/Makefile | 4 +- board/mpl/pati/Makefile | 4 +- board/mpl/pip405/Makefile | 4 +- board/mpl/vcma9/Makefile | 4 +- board/mpr2/Makefile | 4 +- board/ms7720se/Makefile | 4 +- board/ms7722se/Makefile | 4 +- board/ms7750se/Makefile | 4 +- board/muas3001/Makefile | 4 +- board/munices/Makefile | 4 +- board/musenki/Makefile | 4 +- board/mvblue/Makefile | 4 +- board/mx1ads/Makefile | 4 +- board/mx1fs2/Makefile | 4 +- board/netphone/Makefile | 4 +- board/netstal/hcu4/Makefile | 4 +- board/netstal/hcu5/Makefile | 4 +- board/netstal/mcu25/Makefile | 4 +- board/netstar/Makefile | 4 +- board/netta/Makefile | 4 +- board/netta2/Makefile | 4 +- board/netvia/Makefile | 4 +- board/ns9750dev/Makefile | 4 +- board/nx823/Makefile | 4 +- board/o2dnt/Makefile | 4 +- board/overo/Makefile | 4 +- board/oxc/Makefile | 4 +- board/palmld/Makefile | 4 +- board/palmtc/Makefile | 4 +- board/pandora/Makefile | 4 +- board/pb1x00/Makefile | 4 +- board/pcippc2/Makefile | 4 +- board/pcs440ep/Makefile | 4 +- board/pdm360ng/Makefile | 4 +- board/phytec/pcm030/Makefile | 4 +- board/pleb2/Makefile | 4 +- board/pm520/Makefile | 4 +- board/pm826/Makefile | 4 +- board/pm828/Makefile | 4 +- board/pm854/Makefile | 4 +- board/pm856/Makefile | 4 +- board/pn62/Makefile | 4 +- board/ppmc7xx/Makefile | 4 +- board/ppmc8260/Makefile | 4 +- board/prodrive/alpr/Makefile | 4 +- board/prodrive/p3mx/Makefile | 4 +- board/prodrive/p3p440/Makefile | 4 +- board/prodrive/pdnb3/Makefile | 4 +- board/psyent/pci5441/Makefile | 4 +- board/psyent/pk1c20/Makefile | 4 +- board/purple/Makefile | 4 +- board/pxa255_idp/Makefile | 4 +- board/qemu-mips/Makefile | 4 +- board/quad100hd/Makefile | 4 +- board/quantum/Makefile | 4 +- board/r360mpi/Makefile | 4 +- board/rattler/Makefile | 4 +- board/rbc823/Makefile | 4 +- board/renesas/MigoR/Makefile | 4 +- board/renesas/ap325rxa/Makefile | 4 +- board/renesas/r2dplus/Makefile | 4 +- board/renesas/r7780mp/Makefile | 4 +- board/renesas/rsk7203/Makefile | 4 +- board/renesas/sh7763rdp/Makefile | 4 +- board/renesas/sh7785lcr/Makefile | 4 +- board/rmu/Makefile | 4 +- board/ronetix/pm9261/Makefile | 4 +- board/ronetix/pm9263/Makefile | 4 +- board/ronetix/pm9g45/Makefile | 4 +- board/rpxsuper/Makefile | 4 +- board/rsdproto/Makefile | 4 +- board/sacsng/Makefile | 4 +- board/samsung/goni/Makefile | 4 +- board/samsung/smdk2400/Makefile | 4 +- board/samsung/smdk2410/Makefile | 4 +- board/samsung/smdk6400/Makefile | 4 +- board/samsung/smdkc100/Makefile | 4 +- board/sandburst/karef/Makefile | 4 +- board/sandburst/metrobox/Makefile | 4 +- board/sandpoint/Makefile | 4 +- board/sbc2410x/Makefile | 4 +- board/sbc405/Makefile | 4 +- board/sbc8240/Makefile | 4 +- board/sbc8260/Makefile | 4 +- board/sbc8349/Makefile | 4 +- board/sbc8548/Makefile | 4 +- board/sbc8560/Makefile | 4 +- board/sbc8641d/Makefile | 4 +- board/sc3/Makefile | 4 +- board/scb9328/Makefile | 4 +- board/shannon/Makefile | 4 +- board/sheldon/simpc8313/Makefile | 4 +- board/siemens/IAD210/Makefile | 4 +- board/siemens/SCM/Makefile | 4 +- board/siemens/SMN42/Makefile | 4 +- board/sixnet/Makefile | 4 +- board/snmc/qs850/Makefile | 4 +- board/snmc/qs860t/Makefile | 4 +- board/socrates/Makefile | 4 +- board/sorcery/Makefile | 4 +- board/spc1920/Makefile | 4 +- board/spd8xx/Makefile | 4 +- board/spear/common/Makefile | 4 +- board/spear/spear300/Makefile | 4 +- board/spear/spear310/Makefile | 4 +- board/spear/spear320/Makefile | 4 +- board/spear/spear600/Makefile | 4 +- board/st/nhk8815/Makefile | 4 +- board/stx/stxgp3/Makefile | 4 +- board/stx/stxssa/Makefile | 4 +- board/stx/stxxtc/Makefile | 4 +- board/svm_sc8xx/Makefile | 4 +- board/sx1/Makefile | 4 +- board/syteco/jadecpu/Makefile | 4 +- board/t3corp/Makefile | 4 +- board/tb0229/Makefile | 4 +- board/tcm-bf518/Makefile | 4 +- board/tcm-bf537/Makefile | 4 +- board/ti/beagle/Makefile | 4 +- board/ti/evm/Makefile | 4 +- board/ti/omap1510inn/Makefile | 4 +- board/ti/omap1610inn/Makefile | 4 +- board/ti/omap2420h4/Makefile | 4 +- board/ti/omap5912osk/Makefile | 4 +- board/ti/omap730p2/Makefile | 4 +- board/ti/panda/Makefile | 4 +- board/ti/sdp3430/Makefile | 4 +- board/ti/sdp4430/Makefile | 4 +- board/ti/tnetv107xevm/Makefile | 4 +- board/timll/devkit8000/Makefile | 4 +- board/total5200/Makefile | 4 +- board/tqc/tqm5200/Makefile | 4 +- board/tqc/tqm8260/Makefile | 4 +- board/tqc/tqm8272/Makefile | 4 +- board/tqc/tqm834x/Makefile | 4 +- board/tqc/tqm85xx/Makefile | 4 +- board/tqc/tqm8xx/Makefile | 4 +- board/trab/Makefile | 4 +- board/trizepsiv/Makefile | 4 +- board/ttcontrol/vision2/Makefile | 4 +- board/utx8245/Makefile | 4 +- board/v37/Makefile | 4 +- board/v38b/Makefile | 4 +- board/ve8313/Makefile | 4 +- board/voiceblue/Makefile | 4 +- board/vpac270/Makefile | 4 +- board/w7o/Makefile | 4 +- board/westel/amx860/Makefile | 4 +- board/xaeniax/Makefile | 4 +- board/xes/common/Makefile | 4 +- board/xes/xpedite1000/Makefile | 4 +- board/xes/xpedite517x/Makefile | 4 +- board/xes/xpedite520x/Makefile | 4 +- board/xes/xpedite537x/Makefile | 4 +- board/xes/xpedite550x/Makefile | 4 +- board/xilinx/microblaze-generic/Makefile | 4 +- board/xilinx/ppc405-generic/Makefile | 4 +- board/xilinx/ppc440-generic/Makefile | 4 +- board/xm250/Makefile | 4 +- board/zeus/Makefile | 4 +- board/zipitz2/Makefile | 4 +- board/zpc1900/Makefile | 4 +- board/zylonite/Makefile | 4 +- common/Makefile | 4 +- config.mk | 6 ++ disk/Makefile | 4 +- drivers/bios_emulator/Makefile | 4 +- drivers/block/Makefile | 4 +- drivers/dma/Makefile | 4 +- drivers/fpga/Makefile | 4 +- drivers/gpio/Makefile | 4 +- drivers/hwmon/Makefile | 4 +- drivers/i2c/Makefile | 4 +- drivers/input/Makefile | 4 +- drivers/misc/Makefile | 4 +- drivers/mmc/Makefile | 4 +- drivers/mtd/Makefile | 4 +- drivers/mtd/nand/Makefile | 4 +- drivers/mtd/onenand/Makefile | 4 +- drivers/mtd/spi/Makefile | 4 +- drivers/mtd/ubi/Makefile | 4 +- drivers/net/Makefile | 4 +- drivers/net/phy/Makefile | 4 +- drivers/pci/Makefile | 4 +- drivers/pcmcia/Makefile | 4 +- drivers/power/Makefile | 4 +- drivers/qe/Makefile | 4 +- drivers/rtc/Makefile | 4 +- drivers/serial/Makefile | 4 +- drivers/spi/Makefile | 4 +- drivers/twserial/Makefile | 4 +- drivers/usb/gadget/Makefile | 4 +- drivers/usb/host/Makefile | 4 +- drivers/usb/musb/Makefile | 4 +- drivers/usb/phy/Makefile | 4 +- drivers/video/Makefile | 4 +- drivers/watchdog/Makefile | 4 +- examples/standalone/Makefile | 4 +- fs/cramfs/Makefile | 4 +- fs/ext2/Makefile | 4 +- fs/fat/Makefile | 4 +- fs/fdos/Makefile | 4 +- fs/jffs2/Makefile | 4 +- fs/reiserfs/Makefile | 4 +- fs/ubifs/Makefile | 4 +- fs/yaffs2/Makefile | 4 +- include/configs/balloon3.h | 1 + include/configs/palmld.h | 1 + include/configs/palmtc.h | 1 + include/configs/pleb2.h | 1 + include/configs/zipitz2.h | 1 + lib/Makefile | 4 +- lib/libfdt/Makefile | 4 +- lib/lzma/Makefile | 4 +- lib/lzo/Makefile | 4 +- net/Makefile | 4 +- post/Makefile | 20 ++--- post/board/lwmon/Makefile | 2 +- post/board/lwmon5/Makefile | 2 +- post/board/netta/Makefile | 2 +- post/board/pdm360ng/Makefile | 2 +- post/cpu/mpc83xx/Makefile | 2 +- post/cpu/mpc8xx/Makefile | 2 +- post/cpu/ppc4xx/Makefile | 2 +- post/drivers/Makefile | 2 +- post/lib_powerpc/Makefile | 2 +- post/lib_powerpc/fpu/Makefile | 2 +- post/rules.mk | 2 +- 663 files changed, 1380 insertions(+), 1371 deletions(-)
On Tue, Nov 9, 2010 at 9:04 AM, Sebastien Carlier sebastien.carlier@gmail.com wrote:
NOTE: This does not include the actual patch as it is too large for the mailing list (418 kB).
A link to the matching patch would have been nice :)
Regards,
Graeme
On Mon, Nov 8, 2010 at 11:10 PM, Graeme Russ graeme.russ@gmail.com wrote:
On Tue, Nov 9, 2010 at 9:04 AM, Sebastien Carlier sebastien.carlier@gmail.com wrote:
NOTE: This does not include the actual patch as it is too large for the mailing list (418 kB).
A link to the matching patch would have been nice :)
Ah, yes, I was wondering about that...
It looks like I should add it to this page:
http://www.denx.de/wiki/U-Boot/TooBigPatches
I will do so once my registration on the wiki has been processed.
Temporarily, the patch can be found there:
http://io.oiioiio.com/~sebc/0001-Switch-from-archive-libraries-to-partial-li...
Regards,
Sebastien
Dear Sebastien Carlier,
Am 08.11.2010 um 23:04 schrieb Sebastien Carlier:
NOTE: This does not include the actual patch as it is too large for the mailing list (418 kB).
Before this commit, weak symbols were not overridden by non-weak symbols found in archive libraries when linking with recent versions of binutils. As stated in the System V ABI, "the link editor does not extract archive members to resolve undefined weak symbols".
your patch works. Strong symbols in board library now overload weak symbols in other libraries even if they have an alias or empty implementation.
Tested-by: Andreas Bießmann andreas.devel@gmail.com
regards
Andreas Bießmann
Sebastian,
drivers/qe already has an object called "qe.o" ... renaming "qe.a" to "qe.o" doesn't work.
I'd suggest to build libqe.o and also adapt Toplevel Makefile accordingly.
I also don't understand why ftd.c is not depending on CONFIG_QE. That's another question ... but leads to error having your patch applied.
Regards, André
On 11/08/2010 11:04 PM, Sebastien Carlier wrote:
NOTE: This does not include the actual patch as it is too large for the mailing list (418 kB).
Before this commit, weak symbols were not overridden by non-weak symbols found in archive libraries when linking with recent versions of binutils. As stated in the System V ABI, "the link editor does not extract archive members to resolve undefined weak symbols".
This commit changes all Makefiles to use partial linking (ld -r) instead of creating library archives, which forces all symbols to participate in linking, allowing non-weak symbols to override weak symbols as intended. This approach is also used by Linux, from which the gmake function cmd_link_o_target (added at the end of config.mk and used in all Makefiles) is inspired.
The name of each former library archive is preserved except for extensions which change from ".a" to ".o". This commit updates references accordingly where needed, in particular in some linker scripts.
This commit reveals board configurations that exclude some module but not all of its dependencies; for example, disabling CMD_NET but not CMD_NFS results in undefined symbols at link time.
Signed-off-by: Sebastien Carliersebastien.carlier@gmail.com
Makefile | 118 ++++++++++++++-------------- api/Makefile | 4 +- arch/arm/cpu/arm1136/Makefile | 4 +- arch/arm/cpu/arm1136/mx31/Makefile | 4 +- arch/arm/cpu/arm1136/omap24xx/Makefile | 4 +- arch/arm/cpu/arm1176/Makefile | 4 +- arch/arm/cpu/arm1176/s3c64xx/Makefile | 4 +- arch/arm/cpu/arm1176/tnetv107x/Makefile | 4 +- arch/arm/cpu/arm720t/Makefile | 4 +- arch/arm/cpu/arm720t/lpc2292/Makefile | 4 +- arch/arm/cpu/arm720t/s3c4510b/Makefile | 4 +- arch/arm/cpu/arm920t/Makefile | 4 +- arch/arm/cpu/arm920t/a320/Makefile | 4 +- arch/arm/cpu/arm920t/at91/Makefile | 4 +- arch/arm/cpu/arm920t/at91rm9200/Makefile | 4 +- arch/arm/cpu/arm920t/ep93xx/Makefile | 4 +- arch/arm/cpu/arm920t/imx/Makefile | 4 +- arch/arm/cpu/arm920t/ks8695/Makefile | 4 +- arch/arm/cpu/arm920t/s3c24x0/Makefile | 4 +- arch/arm/cpu/arm925t/Makefile | 4 +- arch/arm/cpu/arm926ejs/Makefile | 4 +- arch/arm/cpu/arm926ejs/at91/Makefile | 4 +- arch/arm/cpu/arm926ejs/davinci/Makefile | 4 +- arch/arm/cpu/arm926ejs/kirkwood/Makefile | 4 +- arch/arm/cpu/arm926ejs/mb86r0x/Makefile | 4 +- arch/arm/cpu/arm926ejs/mx25/Makefile | 4 +- arch/arm/cpu/arm926ejs/mx27/Makefile | 4 +- arch/arm/cpu/arm926ejs/nomadik/Makefile | 4 +- arch/arm/cpu/arm926ejs/omap/Makefile | 4 +- arch/arm/cpu/arm926ejs/orion5x/Makefile | 4 +- arch/arm/cpu/arm926ejs/spear/Makefile | 4 +- arch/arm/cpu/arm926ejs/versatile/Makefile | 4 +- arch/arm/cpu/arm946es/Makefile | 4 +- arch/arm/cpu/arm_intcm/Makefile | 4 +- arch/arm/cpu/armv7/Makefile | 4 +- arch/arm/cpu/armv7/mx5/Makefile | 4 +- arch/arm/cpu/armv7/omap-common/Makefile | 4 +- arch/arm/cpu/armv7/omap3/Makefile | 4 +- arch/arm/cpu/armv7/omap4/Makefile | 4 +- arch/arm/cpu/armv7/s5p-common/Makefile | 4 +- arch/arm/cpu/armv7/s5pc1xx/Makefile | 4 +- arch/arm/cpu/ixp/Makefile | 4 +- arch/arm/cpu/ixp/npe/Makefile | 4 +- arch/arm/cpu/lh7a40x/Makefile | 4 +- arch/arm/cpu/pxa/Makefile | 4 +- arch/arm/cpu/s3c44b0/Makefile | 4 +- arch/arm/cpu/sa1100/Makefile | 4 +- arch/arm/lib/Makefile | 10 +- arch/avr32/cpu/Makefile | 4 +- arch/avr32/cpu/at32ap700x/Makefile | 4 +- arch/avr32/lib/Makefile | 4 +- arch/blackfin/cpu/Makefile | 4 +- arch/blackfin/lib/Makefile | 4 +- arch/i386/cpu/Makefile | 4 +- arch/i386/cpu/sc520/Makefile | 4 +- arch/i386/lib/Makefile | 4 +- arch/m68k/cpu/mcf5227x/Makefile | 4 +- arch/m68k/cpu/mcf523x/Makefile | 4 +- arch/m68k/cpu/mcf52x2/Makefile | 4 +- arch/m68k/cpu/mcf532x/Makefile | 4 +- arch/m68k/cpu/mcf5445x/Makefile | 4 +- arch/m68k/cpu/mcf547x_8x/Makefile | 4 +- arch/m68k/lib/Makefile | 4 +- arch/microblaze/cpu/Makefile | 4 +- arch/microblaze/lib/Makefile | 4 +- arch/mips/cpu/Makefile | 4 +- arch/mips/lib/Makefile | 4 +- arch/nios2/cpu/Makefile | 4 +- arch/nios2/lib/Makefile | 4 +- arch/powerpc/cpu/74xx_7xx/Makefile | 4 +- arch/powerpc/cpu/mpc512x/Makefile | 4 +- arch/powerpc/cpu/mpc5xx/Makefile | 4 +- arch/powerpc/cpu/mpc5xxx/Makefile | 4 +- arch/powerpc/cpu/mpc8220/Makefile | 4 +- arch/powerpc/cpu/mpc824x/Makefile | 4 +- arch/powerpc/cpu/mpc8260/Makefile | 4 +- arch/powerpc/cpu/mpc83xx/Makefile | 4 +- arch/powerpc/cpu/mpc85xx/Makefile | 4 +- arch/powerpc/cpu/mpc86xx/Makefile | 4 +- arch/powerpc/cpu/mpc8xx/Makefile | 4 +- arch/powerpc/cpu/mpc8xxx/Makefile | 4 +- arch/powerpc/cpu/mpc8xxx/ddr/Makefile | 4 +- arch/powerpc/cpu/ppc4xx/Makefile | 4 +- arch/powerpc/lib/Makefile | 4 +- arch/sh/cpu/sh2/Makefile | 4 +- arch/sh/cpu/sh3/Makefile | 4 +- arch/sh/cpu/sh4/Makefile | 4 +- arch/sh/lib/Makefile | 4 +- arch/sparc/cpu/leon2/Makefile | 4 +- arch/sparc/cpu/leon3/Makefile | 4 +- arch/sparc/lib/Makefile | 4 +- board/BuS/EB+MCF-EV123/Makefile | 4 +- board/BuS/eb_cpux9k2/Makefile | 4 +- board/LEOX/elpt860/Makefile | 4 +- board/LaCie/edminiv2/Makefile | 4 +- board/Marvell/db64360/Makefile | 4 +- board/Marvell/db64460/Makefile | 4 +- board/Marvell/guruplug/Makefile | 4 +- board/Marvell/mv88f6281gtw_ge/Makefile | 4 +- board/Marvell/openrd_base/Makefile | 4 +- board/Marvell/rd6281a/Makefile | 4 +- board/Marvell/sheevaplug/Makefile | 4 +- board/RPXClassic/Makefile | 4 +- board/RPXlite/Makefile | 4 +- board/RPXlite_dw/Makefile | 4 +- board/RRvision/Makefile | 4 +- board/a3000/Makefile | 4 +- board/a4m072/Makefile | 4 +- board/actux1/Makefile | 4 +- board/actux1/config.mk | 2 +- board/actux2/Makefile | 4 +- board/actux2/config.mk | 2 +- board/actux3/Makefile | 4 +- board/actux3/config.mk | 2 +- board/actux4/Makefile | 4 +- board/actux4/config.mk | 2 +- board/adder/Makefile | 4 +- board/afeb9260/Makefile | 4 +- board/alaska/Makefile | 4 +- board/altera/nios2-generic/Makefile | 4 +- board/amcc/acadia/Makefile | 4 +- board/amcc/bamboo/Makefile | 4 +- board/amcc/bluestone/Makefile | 4 +- board/amcc/bubinga/Makefile | 4 +- board/amcc/canyonlands/Makefile | 4 +- board/amcc/ebony/Makefile | 4 +- board/amcc/katmai/Makefile | 4 +- board/amcc/kilauea/Makefile | 4 +- board/amcc/luan/Makefile | 4 +- board/amcc/makalu/Makefile | 4 +- board/amcc/ocotea/Makefile | 4 +- board/amcc/redwood/Makefile | 4 +- board/amcc/sequoia/Makefile | 4 +- board/amcc/taihu/Makefile | 4 +- board/amcc/taishan/Makefile | 4 +- board/amcc/walnut/Makefile | 4 +- board/amcc/yosemite/Makefile | 4 +- board/amcc/yucca/Makefile | 4 +- board/amirix/ap1000/Makefile | 4 +- board/apollon/Makefile | 4 +- board/armadillo/Makefile | 4 +- board/armltd/integrator/Makefile | 4 +- board/armltd/versatile/Makefile | 4 +- board/armltd/vexpress/Makefile | 4 +- board/assabet/Makefile | 4 +- board/astro/mcf5373l/Makefile | 4 +- board/atc/Makefile | 4 +- board/atmel/at91cap9adk/Makefile | 4 +- board/atmel/at91rm9200dk/Makefile | 4 +- board/atmel/at91rm9200ek/Makefile | 4 +- board/atmel/at91sam9260ek/Makefile | 4 +- board/atmel/at91sam9261ek/Makefile | 4 +- board/atmel/at91sam9263ek/Makefile | 4 +- board/atmel/at91sam9m10g45ek/Makefile | 4 +- board/atmel/at91sam9rlek/Makefile | 4 +- board/atmel/atngw100/Makefile | 4 +- board/atmel/atstk1000/Makefile | 4 +- board/atum8548/Makefile | 4 +- board/balloon3/Makefile | 4 +- board/barco/Makefile | 4 +- board/bc3450/Makefile | 4 +- board/bct-brettl2/Makefile | 4 +- board/bf518f-ezbrd/Makefile | 4 +- board/bf526-ezbrd/Makefile | 4 +- board/bf527-ad7160-eval/Makefile | 4 +- board/bf527-ezkit/Makefile | 4 +- board/bf527-sdp/Makefile | 4 +- board/bf533-ezkit/Makefile | 4 +- board/bf533-stamp/Makefile | 4 +- board/bf537-minotaur/Makefile | 4 +- board/bf537-pnav/Makefile | 4 +- board/bf537-srv1/Makefile | 4 +- board/bf537-stamp/Makefile | 4 +- board/bf538f-ezkit/Makefile | 4 +- board/bf548-ezkit/Makefile | 4 +- board/bf561-acvilon/Makefile | 4 +- board/bf561-ezkit/Makefile | 4 +- board/blackstamp/Makefile | 4 +- board/blackvme/Makefile | 4 +- board/bmw/Makefile | 4 +- board/c2mon/Makefile | 4 +- board/calao/sbc35_a9g20/Makefile | 4 +- board/calao/tny_a9260/Makefile | 4 +- board/canmb/Makefile | 4 +- board/cerf250/Makefile | 4 +- board/cm-bf527/Makefile | 4 +- board/cm-bf533/Makefile | 4 +- board/cm-bf537e/Makefile | 4 +- board/cm-bf537u/Makefile | 4 +- board/cm-bf548/Makefile | 4 +- board/cm-bf561/Makefile | 4 +- board/cm4008/Makefile | 4 +- board/cm41xx/Makefile | 4 +- board/cm5200/Makefile | 4 +- board/cmc_pu2/Makefile | 4 +- board/cmi/Makefile | 4 +- board/cobra5272/Makefile | 4 +- board/cogent/Makefile | 4 +- board/colibri_pxa270/Makefile | 4 +- board/cpc45/Makefile | 4 +- board/cpu86/Makefile | 4 +- board/cpu87/Makefile | 4 +- board/cradle/Makefile | 4 +- board/cray/L1/Makefile | 4 +- board/csb226/Makefile | 4 +- board/csb272/Makefile | 4 +- board/csb472/Makefile | 4 +- board/csb637/Makefile | 4 +- board/cu824/Makefile | 4 +- board/dave/B2/Makefile | 4 +- board/dave/PPChameleonEVB/Makefile | 4 +- board/davedenx/aria/Makefile | 4 +- board/davedenx/qong/Makefile | 4 +- board/davinci/common/Makefile | 4 +- board/davinci/da8xxevm/Makefile | 4 +- board/davinci/dm355evm/Makefile | 4 +- board/davinci/dm355leopard/Makefile | 4 +- board/davinci/dm365evm/Makefile | 4 +- board/davinci/dm6467evm/Makefile | 4 +- board/davinci/dvevm/Makefile | 4 +- board/davinci/schmoogie/Makefile | 4 +- board/davinci/sffsdr/Makefile | 4 +- board/davinci/sonata/Makefile | 4 +- board/dbau1x00/Makefile | 4 +- board/digsy_mtc/Makefile | 4 +- board/dnp1110/Makefile | 4 +- board/eNET/Makefile | 4 +- board/eXalion/Makefile | 4 +- board/earthlcd/favr-32-ezkit/Makefile | 4 +- board/edb93xx/Makefile | 4 +- board/eltec/bab7xx/Makefile | 4 +- board/eltec/elppc/Makefile | 4 +- board/eltec/mhpc/Makefile | 4 +- board/emk/top5200/Makefile | 4 +- board/emk/top860/Makefile | 4 +- board/ep7312/Makefile | 4 +- board/ep8248/Makefile | 4 +- board/ep8260/Makefile | 4 +- board/ep82xxm/Makefile | 4 +- board/ep88x/Makefile | 4 +- board/eric/Makefile | 4 +- board/esd/adciop/Makefile | 4 +- board/esd/apc405/Makefile | 4 +- board/esd/ar405/Makefile | 4 +- board/esd/ash405/Makefile | 4 +- board/esd/canbt/Makefile | 4 +- board/esd/cms700/Makefile | 4 +- board/esd/cpci2dp/Makefile | 4 +- board/esd/cpci405/Makefile | 4 +- board/esd/cpci5200/Makefile | 4 +- board/esd/cpci750/Makefile | 4 +- board/esd/cpciiser4/Makefile | 4 +- board/esd/dasa_sim/Makefile | 4 +- board/esd/dp405/Makefile | 4 +- board/esd/du405/Makefile | 4 +- board/esd/du440/Makefile | 4 +- board/esd/hh405/Makefile | 4 +- board/esd/hub405/Makefile | 4 +- board/esd/mecp5123/Makefile | 4 +- board/esd/mecp5200/Makefile | 4 +- board/esd/meesc/Makefile | 4 +- board/esd/ocrtc/Makefile | 4 +- board/esd/otc570/Makefile | 4 +- board/esd/pci405/Makefile | 6 +- board/esd/pf5200/Makefile | 4 +- board/esd/plu405/Makefile | 4 +- board/esd/pmc405/Makefile | 4 +- board/esd/pmc405de/Makefile | 4 +- board/esd/pmc440/Makefile | 4 +- board/esd/tasreg/Makefile | 4 +- board/esd/vme8349/Makefile | 4 +- board/esd/voh405/Makefile | 4 +- board/esd/vom405/Makefile | 4 +- board/esd/wuh405/Makefile | 4 +- board/espt/Makefile | 4 +- board/esteem192e/Makefile | 4 +- board/etin/debris/Makefile | 4 +- board/etin/kvme080/Makefile | 4 +- board/etx094/Makefile | 4 +- board/eukrea/cpu9260/Makefile | 4 +- board/eukrea/cpuat91/Makefile | 4 +- board/evb4510/Makefile | 4 +- board/evb64260/Makefile | 4 +- board/fads/Makefile | 4 +- board/faraday/a320evb/Makefile | 4 +- board/flagadm/Makefile | 4 +- board/freescale/common/Makefile | 4 +- board/freescale/corenet_ds/Makefile | 4 +- board/freescale/m5208evbe/Makefile | 4 +- board/freescale/m5208evbe/u-boot.lds | 4 +- board/freescale/m52277evb/Makefile | 4 +- board/freescale/m52277evb/u-boot.spa | 6 +- board/freescale/m5235evb/Makefile | 4 +- board/freescale/m5235evb/u-boot.32 | 4 +- board/freescale/m5249evb/Makefile | 4 +- board/freescale/m5253demo/Makefile | 4 +- board/freescale/m5253evbe/Makefile | 4 +- board/freescale/m5271evb/Makefile | 4 +- board/freescale/m5271evb/u-boot.lds | 2 +- board/freescale/m5272c3/Makefile | 4 +- board/freescale/m5275evb/Makefile | 4 +- board/freescale/m5282evb/Makefile | 4 +- board/freescale/m53017evb/Makefile | 4 +- board/freescale/m53017evb/u-boot.lds | 4 +- board/freescale/m5329evb/Makefile | 4 +- board/freescale/m5373evb/Makefile | 4 +- board/freescale/m54451evb/Makefile | 4 +- board/freescale/m54451evb/u-boot.spa | 6 +- board/freescale/m54455evb/Makefile | 4 +- board/freescale/m547xevb/Makefile | 4 +- board/freescale/m548xevb/Makefile | 4 +- board/freescale/mpc5121ads/Makefile | 4 +- board/freescale/mpc7448hpc2/Makefile | 4 +- board/freescale/mpc8260ads/Makefile | 4 +- board/freescale/mpc8266ads/Makefile | 4 +- board/freescale/mpc8308rdb/Makefile | 4 +- board/freescale/mpc8313erdb/Makefile | 4 +- board/freescale/mpc8315erdb/Makefile | 4 +- board/freescale/mpc8323erdb/Makefile | 4 +- board/freescale/mpc832xemds/Makefile | 4 +- board/freescale/mpc8349emds/Makefile | 4 +- board/freescale/mpc8349itx/Makefile | 4 +- board/freescale/mpc8360emds/Makefile | 4 +- board/freescale/mpc8360erdk/Makefile | 4 +- board/freescale/mpc837xemds/Makefile | 4 +- board/freescale/mpc837xerdb/Makefile | 4 +- board/freescale/mpc8536ds/Makefile | 4 +- board/freescale/mpc8540ads/Makefile | 4 +- board/freescale/mpc8541cds/Makefile | 4 +- board/freescale/mpc8544ds/Makefile | 4 +- board/freescale/mpc8548cds/Makefile | 4 +- board/freescale/mpc8555cds/Makefile | 4 +- board/freescale/mpc8560ads/Makefile | 4 +- board/freescale/mpc8568mds/Makefile | 4 +- board/freescale/mpc8569mds/Makefile | 4 +- board/freescale/mpc8572ds/Makefile | 4 +- board/freescale/mpc8610hpcd/Makefile | 4 +- board/freescale/mpc8641hpcn/Makefile | 4 +- board/freescale/mx31ads/Makefile | 4 +- board/freescale/mx31ads/u-boot.lds | 8 +- board/freescale/mx31pdk/Makefile | 4 +- board/freescale/mx51evk/Makefile | 4 +- board/freescale/p1022ds/Makefile | 4 +- board/freescale/p1_p2_rdb/Makefile | 4 +- board/freescale/p2020ds/Makefile | 4 +- board/funkwerk/vovpn-gw/Makefile | 4 +- board/g2000/Makefile | 4 +- board/gaisler/gr_cpci_ax2000/Makefile | 4 +- board/gaisler/gr_ep2s60/Makefile | 4 +- board/gaisler/gr_xc3s_1500/Makefile | 4 +- board/gaisler/grsim/Makefile | 4 +- board/gaisler/grsim_leon2/Makefile | 4 +- board/galaxy5200/Makefile | 4 +- board/gcplus/Makefile | 4 +- board/gdsys/405ep/Makefile | 4 +- board/gdsys/common/Makefile | 4 +- board/gdsys/dlvision/Makefile | 4 +- board/gdsys/gdppc440etx/Makefile | 4 +- board/gdsys/intip/Makefile | 4 +- board/gdsys/neo/Makefile | 4 +- board/gen860t/Makefile | 4 +- board/genietv/Makefile | 4 +- board/gth2/Makefile | 4 +- board/gw8260/Makefile | 4 +- board/hermes/Makefile | 4 +- board/hidden_dragon/Makefile | 4 +- board/hymod/Makefile | 4 +- board/ibf-dsp561/Makefile | 4 +- board/icecube/Makefile | 4 +- board/icu862/Makefile | 4 +- board/idmr/Makefile | 4 +- board/idmr/u-boot.lds | 2 +- board/ids8247/Makefile | 4 +- board/impa7/Makefile | 4 +- board/imx31_phycore/Makefile | 4 +- board/incaip/Makefile | 4 +- board/inka4x0/Makefile | 4 +- board/innokom/Makefile | 4 +- board/ip04/Makefile | 4 +- board/ip860/Makefile | 4 +- board/ipek01/Makefile | 4 +- board/iphase4539/Makefile | 4 +- board/isee/igep0020/Makefile | 4 +- board/isee/igep0030/Makefile | 4 +- board/ispan/Makefile | 4 +- board/ivm/Makefile | 4 +- board/ixdp425/Makefile | 4 +- board/jornada/Makefile | 4 +- board/jse/Makefile | 4 +- board/jupiter/Makefile | 4 +- board/karo/tx25/Makefile | 4 +- board/kb9202/Makefile | 4 +- board/keymile/km8xx/Makefile | 4 +- board/keymile/km_arm/Makefile | 4 +- board/keymile/kmeter1/Makefile | 4 +- board/keymile/mgcoge/Makefile | 4 +- board/korat/Makefile | 4 +- board/kup/Makefile | 4 +- board/kup/kup4k/Makefile | 4 +- board/kup/kup4x/Makefile | 4 +- board/lantec/Makefile | 4 +- board/lart/Makefile | 4 +- board/linkstation/Makefile | 4 +- board/logicpd/am3517evm/Makefile | 4 +- board/logicpd/imx27lite/Makefile | 4 +- board/logicpd/imx31_litekit/Makefile | 4 +- board/logicpd/zoom1/Makefile | 4 +- board/logicpd/zoom2/Makefile | 4 +- board/lpc2292sodimm/Makefile | 4 +- board/lpd7a40x/Makefile | 4 +- board/lubbock/Makefile | 4 +- board/lwmon/Makefile | 4 +- board/lwmon5/Makefile | 4 +- board/m501sk/Makefile | 4 +- board/manroland/hmi1001/Makefile | 4 +- board/manroland/mucmc52/Makefile | 4 +- board/manroland/uc100/Makefile | 4 +- board/manroland/uc101/Makefile | 4 +- board/matrix_vision/common/Makefile | 4 +- board/matrix_vision/mvbc_p/Makefile | 4 +- board/matrix_vision/mvblm7/Makefile | 4 +- board/matrix_vision/mvsmr/Makefile | 4 +- board/mbx8xx/Makefile | 4 +- board/mcc200/Makefile | 4 +- board/micronas/vct/Makefile | 4 +- board/mimc/mimc200/Makefile | 4 +- board/miromico/hammerhead/Makefile | 4 +- board/ml2/Makefile | 4 +- board/modnet50/Makefile | 4 +- board/mosaixtech/icon/Makefile | 4 +- board/motionpro/Makefile | 4 +- board/mousse/Makefile | 4 +- board/mp2usb/Makefile | 4 +- board/mpc8308_p1m/Makefile | 4 +- board/mpc8540eval/Makefile | 4 +- board/mpl/mip405/Makefile | 4 +- board/mpl/pati/Makefile | 4 +- board/mpl/pip405/Makefile | 4 +- board/mpl/vcma9/Makefile | 4 +- board/mpr2/Makefile | 4 +- board/ms7720se/Makefile | 4 +- board/ms7722se/Makefile | 4 +- board/ms7750se/Makefile | 4 +- board/muas3001/Makefile | 4 +- board/munices/Makefile | 4 +- board/musenki/Makefile | 4 +- board/mvblue/Makefile | 4 +- board/mx1ads/Makefile | 4 +- board/mx1fs2/Makefile | 4 +- board/netphone/Makefile | 4 +- board/netstal/hcu4/Makefile | 4 +- board/netstal/hcu5/Makefile | 4 +- board/netstal/mcu25/Makefile | 4 +- board/netstar/Makefile | 4 +- board/netta/Makefile | 4 +- board/netta2/Makefile | 4 +- board/netvia/Makefile | 4 +- board/ns9750dev/Makefile | 4 +- board/nx823/Makefile | 4 +- board/o2dnt/Makefile | 4 +- board/overo/Makefile | 4 +- board/oxc/Makefile | 4 +- board/palmld/Makefile | 4 +- board/palmtc/Makefile | 4 +- board/pandora/Makefile | 4 +- board/pb1x00/Makefile | 4 +- board/pcippc2/Makefile | 4 +- board/pcs440ep/Makefile | 4 +- board/pdm360ng/Makefile | 4 +- board/phytec/pcm030/Makefile | 4 +- board/pleb2/Makefile | 4 +- board/pm520/Makefile | 4 +- board/pm826/Makefile | 4 +- board/pm828/Makefile | 4 +- board/pm854/Makefile | 4 +- board/pm856/Makefile | 4 +- board/pn62/Makefile | 4 +- board/ppmc7xx/Makefile | 4 +- board/ppmc8260/Makefile | 4 +- board/prodrive/alpr/Makefile | 4 +- board/prodrive/p3mx/Makefile | 4 +- board/prodrive/p3p440/Makefile | 4 +- board/prodrive/pdnb3/Makefile | 4 +- board/psyent/pci5441/Makefile | 4 +- board/psyent/pk1c20/Makefile | 4 +- board/purple/Makefile | 4 +- board/pxa255_idp/Makefile | 4 +- board/qemu-mips/Makefile | 4 +- board/quad100hd/Makefile | 4 +- board/quantum/Makefile | 4 +- board/r360mpi/Makefile | 4 +- board/rattler/Makefile | 4 +- board/rbc823/Makefile | 4 +- board/renesas/MigoR/Makefile | 4 +- board/renesas/ap325rxa/Makefile | 4 +- board/renesas/r2dplus/Makefile | 4 +- board/renesas/r7780mp/Makefile | 4 +- board/renesas/rsk7203/Makefile | 4 +- board/renesas/sh7763rdp/Makefile | 4 +- board/renesas/sh7785lcr/Makefile | 4 +- board/rmu/Makefile | 4 +- board/ronetix/pm9261/Makefile | 4 +- board/ronetix/pm9263/Makefile | 4 +- board/ronetix/pm9g45/Makefile | 4 +- board/rpxsuper/Makefile | 4 +- board/rsdproto/Makefile | 4 +- board/sacsng/Makefile | 4 +- board/samsung/goni/Makefile | 4 +- board/samsung/smdk2400/Makefile | 4 +- board/samsung/smdk2410/Makefile | 4 +- board/samsung/smdk6400/Makefile | 4 +- board/samsung/smdkc100/Makefile | 4 +- board/sandburst/karef/Makefile | 4 +- board/sandburst/metrobox/Makefile | 4 +- board/sandpoint/Makefile | 4 +- board/sbc2410x/Makefile | 4 +- board/sbc405/Makefile | 4 +- board/sbc8240/Makefile | 4 +- board/sbc8260/Makefile | 4 +- board/sbc8349/Makefile | 4 +- board/sbc8548/Makefile | 4 +- board/sbc8560/Makefile | 4 +- board/sbc8641d/Makefile | 4 +- board/sc3/Makefile | 4 +- board/scb9328/Makefile | 4 +- board/shannon/Makefile | 4 +- board/sheldon/simpc8313/Makefile | 4 +- board/siemens/IAD210/Makefile | 4 +- board/siemens/SCM/Makefile | 4 +- board/siemens/SMN42/Makefile | 4 +- board/sixnet/Makefile | 4 +- board/snmc/qs850/Makefile | 4 +- board/snmc/qs860t/Makefile | 4 +- board/socrates/Makefile | 4 +- board/sorcery/Makefile | 4 +- board/spc1920/Makefile | 4 +- board/spd8xx/Makefile | 4 +- board/spear/common/Makefile | 4 +- board/spear/spear300/Makefile | 4 +- board/spear/spear310/Makefile | 4 +- board/spear/spear320/Makefile | 4 +- board/spear/spear600/Makefile | 4 +- board/st/nhk8815/Makefile | 4 +- board/stx/stxgp3/Makefile | 4 +- board/stx/stxssa/Makefile | 4 +- board/stx/stxxtc/Makefile | 4 +- board/svm_sc8xx/Makefile | 4 +- board/sx1/Makefile | 4 +- board/syteco/jadecpu/Makefile | 4 +- board/t3corp/Makefile | 4 +- board/tb0229/Makefile | 4 +- board/tcm-bf518/Makefile | 4 +- board/tcm-bf537/Makefile | 4 +- board/ti/beagle/Makefile | 4 +- board/ti/evm/Makefile | 4 +- board/ti/omap1510inn/Makefile | 4 +- board/ti/omap1610inn/Makefile | 4 +- board/ti/omap2420h4/Makefile | 4 +- board/ti/omap5912osk/Makefile | 4 +- board/ti/omap730p2/Makefile | 4 +- board/ti/panda/Makefile | 4 +- board/ti/sdp3430/Makefile | 4 +- board/ti/sdp4430/Makefile | 4 +- board/ti/tnetv107xevm/Makefile | 4 +- board/timll/devkit8000/Makefile | 4 +- board/total5200/Makefile | 4 +- board/tqc/tqm5200/Makefile | 4 +- board/tqc/tqm8260/Makefile | 4 +- board/tqc/tqm8272/Makefile | 4 +- board/tqc/tqm834x/Makefile | 4 +- board/tqc/tqm85xx/Makefile | 4 +- board/tqc/tqm8xx/Makefile | 4 +- board/trab/Makefile | 4 +- board/trizepsiv/Makefile | 4 +- board/ttcontrol/vision2/Makefile | 4 +- board/utx8245/Makefile | 4 +- board/v37/Makefile | 4 +- board/v38b/Makefile | 4 +- board/ve8313/Makefile | 4 +- board/voiceblue/Makefile | 4 +- board/vpac270/Makefile | 4 +- board/w7o/Makefile | 4 +- board/westel/amx860/Makefile | 4 +- board/xaeniax/Makefile | 4 +- board/xes/common/Makefile | 4 +- board/xes/xpedite1000/Makefile | 4 +- board/xes/xpedite517x/Makefile | 4 +- board/xes/xpedite520x/Makefile | 4 +- board/xes/xpedite537x/Makefile | 4 +- board/xes/xpedite550x/Makefile | 4 +- board/xilinx/microblaze-generic/Makefile | 4 +- board/xilinx/ppc405-generic/Makefile | 4 +- board/xilinx/ppc440-generic/Makefile | 4 +- board/xm250/Makefile | 4 +- board/zeus/Makefile | 4 +- board/zipitz2/Makefile | 4 +- board/zpc1900/Makefile | 4 +- board/zylonite/Makefile | 4 +- common/Makefile | 4 +- config.mk | 6 ++ disk/Makefile | 4 +- drivers/bios_emulator/Makefile | 4 +- drivers/block/Makefile | 4 +- drivers/dma/Makefile | 4 +- drivers/fpga/Makefile | 4 +- drivers/gpio/Makefile | 4 +- drivers/hwmon/Makefile | 4 +- drivers/i2c/Makefile | 4 +- drivers/input/Makefile | 4 +- drivers/misc/Makefile | 4 +- drivers/mmc/Makefile | 4 +- drivers/mtd/Makefile | 4 +- drivers/mtd/nand/Makefile | 4 +- drivers/mtd/onenand/Makefile | 4 +- drivers/mtd/spi/Makefile | 4 +- drivers/mtd/ubi/Makefile | 4 +- drivers/net/Makefile | 4 +- drivers/net/phy/Makefile | 4 +- drivers/pci/Makefile | 4 +- drivers/pcmcia/Makefile | 4 +- drivers/power/Makefile | 4 +- drivers/qe/Makefile | 4 +- drivers/rtc/Makefile | 4 +- drivers/serial/Makefile | 4 +- drivers/spi/Makefile | 4 +- drivers/twserial/Makefile | 4 +- drivers/usb/gadget/Makefile | 4 +- drivers/usb/host/Makefile | 4 +- drivers/usb/musb/Makefile | 4 +- drivers/usb/phy/Makefile | 4 +- drivers/video/Makefile | 4 +- drivers/watchdog/Makefile | 4 +- examples/standalone/Makefile | 4 +- fs/cramfs/Makefile | 4 +- fs/ext2/Makefile | 4 +- fs/fat/Makefile | 4 +- fs/fdos/Makefile | 4 +- fs/jffs2/Makefile | 4 +- fs/reiserfs/Makefile | 4 +- fs/ubifs/Makefile | 4 +- fs/yaffs2/Makefile | 4 +- include/configs/balloon3.h | 1 + include/configs/palmld.h | 1 + include/configs/palmtc.h | 1 + include/configs/pleb2.h | 1 + include/configs/zipitz2.h | 1 + lib/Makefile | 4 +- lib/libfdt/Makefile | 4 +- lib/lzma/Makefile | 4 +- lib/lzo/Makefile | 4 +- net/Makefile | 4 +- post/Makefile | 20 ++--- post/board/lwmon/Makefile | 2 +- post/board/lwmon5/Makefile | 2 +- post/board/netta/Makefile | 2 +- post/board/pdm360ng/Makefile | 2 +- post/cpu/mpc83xx/Makefile | 2 +- post/cpu/mpc8xx/Makefile | 2 +- post/cpu/ppc4xx/Makefile | 2 +- post/drivers/Makefile | 2 +- post/lib_powerpc/Makefile | 2 +- post/lib_powerpc/fpu/Makefile | 2 +- post/rules.mk | 2 +- 663 files changed, 1380 insertions(+), 1371 deletions(-)
U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
Dear André,
On 2010-11-09 10:15:31, Andre Schwarz wrote:
Date: Tue, 09 Nov 2010 10:15:31 +0100 From: Andre Schwarz andre.schwarz@matrix-vision.de To: Sebastien Carlier sebastien.carlier@gmail.com CC: u-boot@lists.denx.de, Timur Tabi timur@freescale.com, Kim Phillips kim.phillips@freescale.com Subject: Re: [U-Boot] [PATCH] Switch from archive libraries to partial linking User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.15) Gecko/20101027 Thunderbird/3.0.10
Sebastian,
drivers/qe already has an object called "qe.o" ... renaming "qe.a" to "qe.o" doesn't work.
Thanks!
I'd suggest to build libqe.o and also adapt Toplevel Makefile accordingly.
I did as you suggested, version 2 of the patch is available here:
http://www.denx.de/wiki/pub/U-Boot/TooBigPatches/0001-Switch-from-archive-li...
I also don't understand why ftd.c is not depending on CONFIG_QE. That's another question ... but leads to error having your patch applied.
Right, fdt.c should not be included in the build unless both CONFIG_QE and CONFIG_OF_LIBFDT are defined. Previously this issue was hidden because all of qe.a was discarded by the linker. Would the following be a good fix for this problem?
-COBJS-$(CONFIG_OF_LIBFDT) += fdt.o +COBJS-$(and $(CONFIG_QE),$(CONFIG_OF_LIBFDT)) += fdt.o
Regards,
Sebastien,
I also don't understand why ftd.c is not depending on CONFIG_QE. That's another question ... but leads to error having your patch applied.
Right, fdt.c should not be included in the build unless both CONFIG_QE and CONFIG_OF_LIBFDT are defined. Previously this issue was hidden because all of qe.a was discarded by the linker. Would the following be a good fix for this problem?
-COBJS-$(CONFIG_OF_LIBFDT) += fdt.o +COBJS-$(and $(CONFIG_QE),$(CONFIG_OF_LIBFDT)) += fdt.o
yes - this should do it. Within fdt.c there's a CONFIG_QE conditional - you can remove this also with your approach.
Regards, André
MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
On 09/11/10 09:04, Sebastien Carlier wrote:
NOTE: This does not include the actual patch as it is too large for the mailing list (418 kB).
Signed-off-by: Sebastien Carlier sebastien.carlier@gmail.com
Patch applies with zero errors or warnings to my x86 branch, builds clean, runs and, as a bonus, allows me to move the sc520 reset_cpu() which has an ugly #ifdef in sc520.c into it's own file (with archives, if the archive contained only overrides of weak functions, they would be skipped - I think the archive needed at least the first function to not be an override of a weak function)
So I'm a very happy (one less #ifdef) camper
Tested-by: Graeme Russ graeme.russ@gmail.com
On 11/08/2010 11:04 PM, Sebastien Carlier wrote:
NOTE: This does not include the actual patch as it is too large for the mailing list (418 kB).
Your patch applies fine to i.MX branch - boards compile clean, tested on a MX.51 board.
Tested-by: Stefano Babic sbabic@denx.de
Best regards, Stefano Babic
On Monday, November 08, 2010 17:04:32 Sebastien Carlier wrote:
This commit changes all Makefiles to use partial linking (ld -r) instead of creating library archives, which forces all symbols to participate in linking, allowing non-weak symbols to override weak symbols as intended. This approach is also used by Linux, from which the gmake function cmd_link_o_target (added at the end of config.mk and used in all Makefiles) is inspired.
wish we could integrate this into one place already. all these Makefile's duplicating targets sucks a lot. but guess that could be a future change.
the config.mk looks weird: +cmd_link_o_target = $(if $(strip $1),\ + $(LD) -r -o $@ $1 ,\ + rm -f $@; $(AR) rcs $@ )
why do you need the rm/ar ?
post/board/lwmon/Makefile | 2 +- post/board/lwmon5/Makefile | 2 +- post/board/netta/Makefile | 2 +- post/board/pdm360ng/Makefile | 2 +- post/cpu/mpc83xx/Makefile | 2 +- post/cpu/mpc8xx/Makefile | 2 +- post/cpu/ppc4xx/Makefile | 2 +- post/drivers/Makefile | 2 +- post/lib_powerpc/Makefile | 2 +- post/lib_powerpc/fpu/Makefile | 2 +- post/rules.mk | 2 +-
these look like useless whitespace changes. a lot of the LIB= changes have similar useless changes. looks like your sed needs a little more smarts to retain whitespace: -e '/^LIB/s:[.]a$:.o:' -mike
Dear Mike Frysinger,
Am 10.11.2010 07:57, schrieb Mike Frysinger:
On Monday, November 08, 2010 17:04:32 Sebastien Carlier wrote:
the config.mk looks weird: +cmd_link_o_target = $(if $(strip $1),\
$(LD) -r -o $@ $1 ,\rm -f $@; $(AR) rcs $@ )why do you need the rm/ar ?
If one input ($1) is empty the linker ($(LD) -r) would complain empty input. Therefore we buid an empty archive with $(AR) rcs
regards
Andreas Bießmann
Dear Mike,
On 2010-11-10 01:57:30, Mike Frysinger wrote:
On Monday, November 08, 2010 17:04:32 Sebastien Carlier wrote:
This commit changes all Makefiles to use partial linking (ld -r) instead of creating library archives, which forces all symbols to participate in linking, allowing non-weak symbols to override weak symbols as intended. This approach is also used by Linux, from which the gmake function cmd_link_o_target (added at the end of config.mk and used in all Makefiles) is inspired.
wish we could integrate this into one place already. all these Makefile's duplicating targets sucks a lot. but guess that could be a future change.
It would be nice to have a single rule for all libraries, but I see no reason to do it all at once (and at the same time as fixing an separate issue). Some Makefile's do things a little differently from others and each would best be handled by their respective maintainer.
the config.mk looks weird: +cmd_link_o_target = $(if $(strip $1),\
$(LD) -r -o $@ $1 ,\rm -f $@; $(AR) rcs $@ )why do you need the rm/ar ?
The ar part is needed when there are no objets to link, as ld cannot create an empty object out of nothing. The rm part is to make sure that the target is not a leftover object from a previous build (ar would complain).
these look like useless whitespace changes. a lot of the LIB= changes have similar useless changes. looks like your sed needs a little more smarts to retain whitespace: -e '/^LIB/s:[.]a$:.o:'
Good suggestion, done in v3:
http://www.denx.de/wiki/pub/U-Boot/TooBigPatches/0001-Switch-from-archive-li...
Regards,
On Wednesday, November 10, 2010 03:07:08 Sebastien Carlier wrote:
On 2010-11-10 01:57:30, Mike Frysinger wrote:
the config.mk looks weird: +cmd_link_o_target = $(if $(strip $1),\
$(LD) -r -o $@ $1 ,\rm -f $@; $(AR) rcs $@ )why do you need the rm/ar ?
The ar part is needed when there are no objets to link, as ld cannot create an empty object out of nothing. The rm part is to make sure that the target is not a leftover object from a previous build (ar would complain).
if you're going to copy from linux, you should move over relevant comments: # If the list of objects to link is empty, just create an empty built-in.o -mike
On 2010-11-10 03:55:21, Mike Frysinger wrote:
On Wednesday, November 10, 2010 03:07:08 Sebastien Carlier wrote:
On 2010-11-10 01:57:30, Mike Frysinger wrote:
the config.mk looks weird: +cmd_link_o_target = $(if $(strip $1),\
$(LD) -r -o $@ $1 ,\rm -f $@; $(AR) rcs $@ )why do you need the rm/ar ?
The ar part is needed when there are no objets to link, as ld cannot create an empty object out of nothing. The rm part is to make sure that the target is not a leftover object from a previous build (ar would complain).
if you're going to copy from linux, you should move over relevant comments: # If the list of objects to link is empty, just create an empty built-in.o
I will include this comment in the next version of the patch.
I was wondering whether config.mk is the right place for this function; would it be better in rules.mk instead? Both config.mk and rules.mk end up being included in all Makefile's.
Regards,
On Wednesday, November 10, 2010 07:24:51 Sebastien Carlier wrote:
I was wondering whether config.mk is the right place for this function; would it be better in rules.mk instead? Both config.mk and rules.mk end up being included in all Makefile's.
for now, keep it with the other compiler targets. that means the end of config.mk. -mike
Dear Sebastien Carlier,
In message 20101110080708.GA8145@safe.home.local you wrote:
Good suggestion, done in v3:
I have to admit that I lost a bit of overview of the current state of this work. My understanding is that you are preparing a new version (V4 ?) of this patch?
If yes, do you have any estimates when this will be available?
I think this an important patch, so I would like to get this in without further delay.
Thanks.
Best regards,
Wolfgang Denk
Dear Wolfgang,
On 2010-11-15 08:51:29, Wolfgang Denk wrote:
In message 20101110080708.GA8145@safe.home.local you wrote:
Good suggestion, done in v3:
I have to admit that I lost a bit of overview of the current state of this work. My understanding is that you are preparing a new version (V4 ?) of this patch?
If yes, do you have any estimates when this will be available?
I just uploaded the revised patch here:
http://www.denx.de/wiki/pub/U-Boot/TooBigPatches/0001-Switch-from-archive-li...
Version 4: Bring in Linux comment for cmd_link_o_target. Fix drivers/qe/Makefile to build libqe.o, not qe.o.
I pulled the latest changes before making the patch and there was no conflict, but please let me know if you see anything wrong with it.
Dear Sebastien Carlier,
In message 20101115080950.GA26767@safe.home.local you wrote:
I just uploaded the revised patch here:
http://www.denx.de/wiki/pub/U-Boot/TooBigPatches/0001-Switch-from-archive-li...
Version 4: Bring in Linux comment for cmd_link_o_target. Fix drivers/qe/Makefile to build libqe.o, not qe.o.
I pulled the latest changes before making the patch and there was no conflict, but please let me know if you see anything wrong with it.
Thanks a lot.
I notice that the patch affects the size of the resulting U-Boot images.
For example:
Configuring for MiniFAP - Board: TQM5200, Options: MINIFAP text data bss dec hex filename 358144 35208 303248 696600 aa118 ./u-boot before 361340 35824 303332 700496 ab050 ./u-boot after ------------------------------- Delta: +3896 Bytes
For other boards it's only a few hundred bytes, but why do we see such big increase here?
MPC8xx boards break with long lists of multiple definitions of symbols, like that:
Configuring for FPS860L board... lib/libgeneric.o: In function `vsprintf': /home/wd/git/u-boot/work/lib/vsprintf.c:480: multiple definition of `vsprintf' lib/vsprintf.o:/home/wd/git/u-boot/work/lib/vsprintf.c:480: first defined here lib/libgeneric.o: In function `ustrtoul': /home/wd/git/u-boot/work/lib/vsprintf.c:74: multiple definition of `ustrtoul' lib/vsprintf.o:/home/wd/git/u-boot/work/lib/vsprintf.c:74: first defined here lib/libgeneric.o: In function `simple_strtol': /home/wd/git/u-boot/work/lib/vsprintf.c:67: multiple definition of `simple_strtol' lib/vsprintf.o:/home/wd/git/u-boot/work/lib/vsprintf.c:67: first defined here lib/libgeneric.o: In function `inflate': /home/wd/git/u-boot/work/lib/zlib.c:1385: multiple definition of `inflate' lib/zlib.o:/home/wd/git/u-boot/work/lib/zlib.c:1385: first defined here lib/libgeneric.o: In function `inflate_fast': /home/wd/git/u-boot/work/lib/zlib.c:448: multiple definition of `inflate_fast' lib/zlib.o:/home/wd/git/u-boot/work/lib/zlib.c:448: first defined here ...
Have you seen that, too?
Best regards, Viele Grüße,
Wolfgang Denk
On Monday, November 15, 2010 05:54:07 Wolfgang Denk wrote:
Sebastien Carlier wrote:
I just uploaded the revised patch here: http://www.denx.de/wiki/pub/U-Boot/TooBigPatches/0001-Switch-from-archiv e-libraries-to-partial-linking-v4.patch
Version 4: Bring in Linux comment for cmd_link_o_target. Fix drivers/qe/Makefile to build libqe.o, not qe.o.
I pulled the latest changes before making the patch and there was no conflict, but please let me know if you see anything wrong with it.
Thanks a lot.
I notice that the patch affects the size of the resulting U-Boot images.
For example:
Configuring for MiniFAP - Board: TQM5200, Options: MINIFAP text data bss dec hex filename 358144 35208 303248 696600 aa118 ./u-boot before 361340 35824 303332 700496 ab050 ./u-boot after
Delta: +3896 BytesFor other boards it's only a few hundred bytes, but why do we see such big increase here?
some of this is probably because of missing build system support. there are some files which are always compiled when they shouldnt be but in the past, this wasnt a problem because they were stuck in an .a and the linker wouldnt pull them in since no one requested them.
on my side, i see this with at least these files: cmd_pcmcia.c file.c ldiv.c memsize.c rpx_pcmcia.c tqm8xx_pcmcia.c
although i'm still seeing a few hundred byte increase in my .text/.bss, but the symbol map is unchanged ... -mike
On Monday, November 15, 2010 06:33:40 Mike Frysinger wrote:
On Monday, November 15, 2010 05:54:07 Wolfgang Denk wrote:
Sebastien Carlier wrote:
I just uploaded the revised patch here: http://www.denx.de/wiki/pub/U-Boot/TooBigPatches/0001-Switch-from-
arch
iv e-libraries-to-partial-linking-v4.patch
Version 4: Bring in Linux comment for cmd_link_o_target. Fix drivers/qe/Makefile to build libqe.o, not qe.o.
I pulled the latest changes before making the patch and there was no conflict, but please let me know if you see anything wrong with it.
Thanks a lot.
I notice that the patch affects the size of the resulting U-Boot images.
For example:
Configuring for MiniFAP - Board: TQM5200, Options: MINIFAP
text data bss dec hex filename
358144 35208 303248 696600 aa118 ./u-boot before 361340 35824 303332 700496 ab050 ./u-boot after
Delta: +3896 BytesFor other boards it's only a few hundred bytes, but why do we see such big increase here?
some of this is probably because of missing build system support. there are some files which are always compiled when they shouldnt be but in the past, this wasnt a problem because they were stuck in an .a and the linker wouldnt pull them in since no one requested them.
on my side, i see this with at least these files: cmd_pcmcia.c file.c ldiv.c memsize.c rpx_pcmcia.c tqm8xx_pcmcia.c
although i'm still seeing a few hundred byte increase in my .text/.bss, but the symbol map is unchanged ...
some of this is simply due to change in linking order and the implicit padding in between each symbol for alignment requirements
you can check how much this adds with the attached script: $ ./align-padding u-boot .text | tail -n1 586 $ ./align-padding old/u-boot .text | tail -n1 490
replace the '$7 == "3"' check with whatever section number you want to check. in my case, 3 is ".text". i see a 96 byte change in my .text due to this, but i wouldnt blame this patch for it. and similar changes for .data/.bss/.rodata. -mike
On Monday, November 15, 2010 07:38:28 Mike Frysinger wrote:
replace the '$7 == "3"' check with whatever section number you want to check. in my case, 3 is ".text".
err, ignore this outdated comment -mike
On Monday, November 15, 2010 07:38:28 Mike Frysinger wrote:
some of this is simply due to change in linking order and the implicit padding in between each symbol for alignment requirements
you can check how much this adds with the attached script:
this version fixes handling with defined weak symbols and with very large symbols (readelf will use hex for them) -mike
Dear Wolfgang,
On 2010-11-15 11:54:07, Wolfgang Denk wrote:
I notice that the patch affects the size of the resulting U-Boot images.
For example:
Configuring for MiniFAP - Board: TQM5200, Options: MINIFAP text data bss dec hex filename 358144 35208 303248 696600 aa118 ./u-boot before 361340 35824 303332 700496 ab050 ./u-boot after
Delta: +3896 BytesFor other boards it's only a few hundred bytes, but why do we see such big increase here?
With archive library linking, definitions that were not used were not included in the final binary. This changes with partial linking (like it would if we passed the --whole-archive flag to ld).
For this board (TQM5200), I am not sure exactly what happens yet, but this looks suspect to me:
# ls -l ./post/lib_powerpc/fpu/mul-subnormal-single-1.[co] -rw-r--r-- 1 sebc sebc 2309 Nov 1 21:33 ./post/lib_powerpc/fpu/mul-subnormal-single-1.c -rw-r--r-- 1 sebc sebc 30288 Nov 15 12:09 ./post/lib_powerpc/fpu/mul-subnormal-single-1.o
I would expect the object file to be much smaller based on source code size.
MPC8xx boards break with long lists of multiple definitions of symbols, like that:
Configuring for FPS860L board... lib/libgeneric.o: In function `vsprintf': /home/wd/git/u-boot/work/lib/vsprintf.c:480: multiple definition of `vsprintf' lib/vsprintf.o:/home/wd/git/u-boot/work/lib/vsprintf.c:480: first defined here lib/libgeneric.o: In function `ustrtoul': /home/wd/git/u-boot/work/lib/vsprintf.c:74: multiple definition of `ustrtoul' lib/vsprintf.o:/home/wd/git/u-boot/work/lib/vsprintf.c:74: first defined here lib/libgeneric.o: In function `simple_strtol': /home/wd/git/u-boot/work/lib/vsprintf.c:67: multiple definition of `simple_strtol' lib/vsprintf.o:/home/wd/git/u-boot/work/lib/vsprintf.c:67: first defined here lib/libgeneric.o: In function `inflate': /home/wd/git/u-boot/work/lib/zlib.c:1385: multiple definition of `inflate' lib/zlib.o:/home/wd/git/u-boot/work/lib/zlib.c:1385: first defined here lib/libgeneric.o: In function `inflate_fast': /home/wd/git/u-boot/work/lib/zlib.c:448: multiple definition of `inflate_fast' lib/zlib.o:/home/wd/git/u-boot/work/lib/zlib.c:448: first defined here ...
Have you seen that, too?
No, I had not seen that. It seems that some bits of U-Boot get included twice in this case... I will investigate this after looking a bit more at the code size increase for the TQM5200 board.
On 2010-11-15 11:54:07, Wolfgang Denk wrote:
I notice that the patch affects the size of the resulting U-Boot images.
For example:
Configuring for MiniFAP - Board: TQM5200, Options: MINIFAP text data bss dec hex filename 358144 35208 303248 696600 aa118 ./u-boot before 361340 35824 303332 700496 ab050 ./u-boot after
Delta: +3896 BytesFor other boards it's only a few hundred bytes, but why do we see such big increase here?
In this case, these libraries contribute 3260 bytes in unused definitions:
- fs/fat/libfat.a: (1712 bytes) file.o: 00000000 00000004 d current_filesystem 00000004 00000200 D file_cwd 00000000 00000018 d filesystems 00000250 00000244 T file_cd 000001d0 00000080 T file_detectfs 00000000 00000048 T file_getfsname 0000011c 000000b4 T file_ls 00000048 000000d4 T file_read
- lib/libfdt/libfdt.a (1440 bytes) fdt_sw.o: 00000000 0000006c T fdt_add_reservemap_entry 0000028c 000000dc T fdt_begin_node 00000504 0000009c T fdt_create 000000b4 00000078 T fdt_end_node 0000012c 00000160 T fdt_finish 0000006c 00000048 T fdt_finish_reservemap 00000368 0000019c T fdt_property
- drivers/pci/libpci.a: (108 bytes) pci_indirect.o: 000001dc 0000006c T pci_setup_indirect
In each case, a whole object file contains exactly the unused definitions, and could be excluded in the respective Makefile.
Re. my previous comment -- in other places objects get large when header files define a lot of static inline functions, but these ('t' type) definitions get squashed together during linking and do not add up. If however a large static inline function is defined but never used, it will increase final binary size.
On Monday, November 15, 2010 07:13:03 Sebastien Carlier wrote:
On 2010-11-15 11:54:07, Wolfgang Denk wrote:
I notice that the patch affects the size of the resulting U-Boot images.
For example:
Configuring for MiniFAP - Board: TQM5200, Options: MINIFAP
text data bss dec hex filename
358144 35208 303248 696600 aa118 ./u-boot before 361340 35824 303332 700496 ab050 ./u-boot after
Delta: +3896 BytesFor other boards it's only a few hundred bytes, but why do we see such big increase here?
In this case, these libraries contribute 3260 bytes in unused definitions:
In each case, a whole object file contains exactly the unused definitions, and could be excluded in the respective Makefile.
or just use -ffunction-sections/-fdata-sections/-Wl,--gc-sections and dont worry about it. which is what we do for the Blackfin port. -mike
Hi,
On Monday, November 15, 2010 07:13:03 Sebastien Carlier wrote:
On 2010-11-15 11:54:07, Wolfgang Denk wrote:
I notice that the patch affects the size of the resulting U-Boot images.
For example:
Configuring for MiniFAP - Board: TQM5200, Options: MINIFAP
text data bss dec hex filename
358144 35208 303248 696600 aa118 ./u-boot before 361340 35824 303332 700496 ab050 ./u-boot after
Delta: +3896 BytesFor other boards it's only a few hundred bytes, but why do we see such big increase here?
In this case, these libraries contribute 3260 bytes in unused definitions:
In each case, a whole object file contains exactly the unused definitions, and could be excluded in the respective Makefile.
or just use -ffunction-sections/-fdata-sections/-Wl,--gc-sections and dont worry about it. which is what we do for the Blackfin port.
If you do worry, you can use the "--gc-sections" together with "--print-gc-sections" to actually find out what is unused[1].
Cheers Detlev
[1] http://article.gmane.org/gmane.comp.boot-loaders.u-boot/84971/
On Tuesday, November 16, 2010 09:58:48 Detlev Zundel wrote:
On Monday, November 15, 2010 07:13:03 Sebastien Carlier wrote:
On 2010-11-15 11:54:07, Wolfgang Denk wrote:
I notice that the patch affects the size of the resulting U-Boot images.
For example:
Configuring for MiniFAP - Board: TQM5200, Options: MINIFAP
text data bss dec hex filename
358144 35208 303248 696600 aa118 ./u-boot before 361340 35824 303332 700496 ab050 ./u-boot after
Delta: +3896 BytesFor other boards it's only a few hundred bytes, but why do we see such big increase here?
In this case, these libraries contribute 3260 bytes in unused definitions:
In each case, a whole object file contains exactly the unused definitions, and could be excluded in the respective Makefile.
or just use -ffunction-sections/-fdata-sections/-Wl,--gc-sections and dont worry about it. which is what we do for the Blackfin port.
If you do worry, you can use the "--gc-sections" together with "--print-gc-sections" to actually find out what is unused[1].
the u-boot.map also mentions which input sections are discarded without needing --print-gc-sections ... -mike
Hi Mike,
On Tuesday, November 16, 2010 09:58:48 Detlev Zundel wrote:
On Monday, November 15, 2010 07:13:03 Sebastien Carlier wrote:
On 2010-11-15 11:54:07, Wolfgang Denk wrote:
I notice that the patch affects the size of the resulting U-Boot images.
For example:
Configuring for MiniFAP - Board: TQM5200, Options: MINIFAP
text data bss dec hex filename
358144 35208 303248 696600 aa118 ./u-boot before 361340 35824 303332 700496 ab050 ./u-boot after
Delta: +3896 BytesFor other boards it's only a few hundred bytes, but why do we see such big increase here?
In this case, these libraries contribute 3260 bytes in unused definitions:
In each case, a whole object file contains exactly the unused definitions, and could be excluded in the respective Makefile.
or just use -ffunction-sections/-fdata-sections/-Wl,--gc-sections and dont worry about it. which is what we do for the Blackfin port.
If you do worry, you can use the "--gc-sections" together with "--print-gc-sections" to actually find out what is unused[1].
the u-boot.map also mentions which input sections are discarded without needing --print-gc-sections ...
Intersting, I didn't realize this. Thanks! Detlev
Dear Wolfgang,
On 2010-11-15 11:54:07, Wolfgang Denk wrote:
I notice that the patch affects the size of the resulting U-Boot images.
The size increase you noted seems to completely go away when adding --gc-sections to LDFLAGS, but this option apparently brings its own issues when the linker discards important unreferenced bits:
http://www.mail-archive.com/u-boot@lists.denx.de/msg41762.html http://www.mail-archive.com/u-boot@lists.denx.de/msg42063.html
These problems can be fixed within linker scripts, but I think it might be safer to use --gc-sections for diagnostic purposes only...
MPC8xx boards break with long lists of multiple definitions of symbols, like that:
Configuring for FPS860L board... lib/libgeneric.o: In function `vsprintf': /home/wd/git/u-boot/work/lib/vsprintf.c:480: multiple definition of `vsprintf' ...
Have you seen that, too?
Unfortunately I have not been able to reproduce these errors with the toolchain I am using (gcc 4.4.5 and binutils 2.20.1.20100303, based on emdebian squeeze packages). Can you please point me to the toolchain you are using?
Regards,
Dear Sebastien Carlier,
In message 20101117133056.GB23875@safe.home.local you wrote:
Unfortunately I have not been able to reproduce these errors with the toolchain I am using (gcc 4.4.5 and binutils 2.20.1.20100303, based on emdebian squeeze packages). Can you please point me to the toolchain you are using?
I'm using ELDk 4.2 as reference. Please see ftp://ftp.denx.de/pub/eldk/4.2/ppc-linux-x86/iso/
Best regards,
Wolfgang Denk
On Wednesday, November 17, 2010 08:30:56 Sebastien Carlier wrote:
On 2010-11-15 11:54:07, Wolfgang Denk wrote:
I notice that the patch affects the size of the resulting U-Boot images.
The size increase you noted seems to completely go away when adding --gc-sections to LDFLAGS, but this option apparently brings its own issues when the linker discards important unreferenced bits:
http://www.mail-archive.com/u-boot@lists.denx.de/msg41762.html http://www.mail-archive.com/u-boot@lists.denx.de/msg42063.htmlThese problems can be fixed within linker scripts, but I think it might be safer to use --gc-sections for diagnostic purposes only...
it's really not that hard to fix things to work with --gc-sections (ive been using it on Blackfin for literally years at this point). people really should be driving to have that supported everywhere. -mike
Dear Mike,
On 2010-11-17 13:06:49, Mike Frysinger wrote:
On Wednesday, November 17, 2010 08:30:56 Sebastien Carlier wrote:
On 2010-11-15 11:54:07, Wolfgang Denk wrote:
I notice that the patch affects the size of the resulting U-Boot images.
The size increase you noted seems to completely go away when adding --gc-sections to LDFLAGS, but this option apparently brings its own issues when the linker discards important unreferenced bits:
http://www.mail-archive.com/u-boot@lists.denx.de/msg41762.html http://www.mail-archive.com/u-boot@lists.denx.de/msg42063.htmlThese problems can be fixed within linker scripts, but I think it might be safer to use --gc-sections for diagnostic purposes only...
it's really not that hard to fix things to work with --gc-sections (ive been using it on Blackfin for literally years at this point). people really should be driving to have that supported everywhere.
Maybe I was being overly conservative. With --gc-sections, I assume the linker only needs to be told to keep any section that has no external references to it, which would only include startup code and reset vectors. Is that accurate? Is there any other case that may need special handling?
I suppose -ffunction-sections and -fdata-sections increase compile time; are they worth it in practice? The few cases I have seen involved whole objects being unused, so just --gc-sections would deal with them.
On Wednesday, November 17, 2010 14:53:33 Sebastien Carlier wrote:
On 2010-11-17 13:06:49, Mike Frysinger wrote:
On Wednesday, November 17, 2010 08:30:56 Sebastien Carlier wrote:
The size increase you noted seems to completely go away when adding --gc-sections to LDFLAGS, but this option apparently brings its own
issues when the linker discards important unreferenced bits: http://www.mail-archive.com/u-boot@lists.denx.de/msg41762.html http://www.mail-archive.com/u-boot@lists.denx.de/msg42063.html
These problems can be fixed within linker scripts, but I think it might be safer to use --gc-sections for diagnostic purposes only...
it's really not that hard to fix things to work with --gc-sections (ive been using it on Blackfin for literally years at this point). people really should be driving to have that supported everywhere.
Maybe I was being overly conservative. With --gc-sections, I assume the linker only needs to be told to keep any section that has no external references to it, which would only include startup code and reset vectors. Is that accurate?
yes
Is there any other case that may need special handling?
the u-boot command handling is a bit funky and needs handling, but that was implemented years ago in common code, so ports need not worry about it
I suppose -ffunction-sections and -fdata-sections increase compile time; are they worth it in practice?
in practice, the difference is irrelevant. for the bf548-ezkit build (a fairly large image -- in the 512KiB range), i run on a dual core system: git clean -x -d -q time make -s -j2 bf548-ezkit
with the section flags, i get ~5.7 seconds. without, i get ~5.1 seconds.
The few cases I have seen involved whole objects being unused, so just --gc-sections would deal with them.
it also takes care of unused common code and library functions. for Blackfin systems, i provide the full common GPIO API in one file, but any local funcs that no one uses all get discarded.
it also keeps down horrible ifdef messes where the only point point would be to move gcc's DCE step to CPP.
again, to refer to the bf548-ezkit, i get ~10KB of .text removed by this alone -mike
Dear Sebastien Carlier,
In message 20101117133056.GB23875@safe.home.local you wrote:
MPC8xx boards break with long lists of multiple definitions of symbols, like that:
Configuring for FPS860L board... lib/libgeneric.o: In function `vsprintf': /home/wd/git/u-boot/work/lib/vsprintf.c:480: multiple definition of `vsprintf' ...
Have you seen that, too?
Unfortunately I have not been able to reproduce these errors with the toolchain I am using (gcc 4.4.5 and binutils 2.20.1.20100303, based on emdebian squeeze packages). Can you please point me to the toolchain you are using?
Are you sure this doesn't happen with your tool chain?
I found out why this happens, and I think the effect should be independent of the used tool chain:
For example, in "board/tqc/tqm8xx/u-boot.lds" we arrange to have the environment located in one of the "small" NOR flash sectors:
... 53 .text : 54 { 55 /* WARNING - the following is hand-optimized to fit within */ 56 /* the sector layout of our flash chips! XXX FIXME XXX */ 57 58 arch/powerpc/cpu/mpc8xx/start.o (.text) 59 arch/powerpc/cpu/mpc8xx/traps.o (.text) 60 common/dlmalloc.o (.text) 61 arch/powerpc/lib/ppcstring.o (.text) 62 lib/vsprintf.o (.text) 63 lib/crc32.o (.text) 64 lib/zlib.o (.text) 65 arch/powerpc/lib/cache.o (.text) 66 67 . = DEFINED(env_offset) ? env_offset : .; 68 common/env_embedded.o (.ppcenv) 69 70 *(.text) 71 *(.got1) ...
That means, the linker script pulls in certain object files directly. Before, when linking with libraries, this was no problem, as the linker would pull only (so far) unresolved symbols from the libraries specified on the command line. Now, we include these individual object files through the linker script, and then again when specifying the "library" objects on the command line - which necessarily results in "multiple definition" errors.
Unfortunately I don't know how to solve this yet. Does anybody know of a way how to manually arrange the objects (or symbols) in the linked image?
Best regards,
Wolfgang Denk
Le 18/11/2010 22:44, Wolfgang Denk a écrit :
Dear Sebastien Carlier,
In message20101117133056.GB23875@safe.home.local you wrote:
MPC8xx boards break with long lists of multiple definitions of symbols, like that:
Configuring for FPS860L board... lib/libgeneric.o: In function `vsprintf': /home/wd/git/u-boot/work/lib/vsprintf.c:480: multiple definition of `vsprintf' ...
Have you seen that, too?
Unfortunately I have not been able to reproduce these errors with the toolchain I am using (gcc 4.4.5 and binutils 2.20.1.20100303, based on emdebian squeeze packages). Can you please point me to the toolchain you are using?
Are you sure this doesn't happen with your tool chain?
I found out why this happens, and I think the effect should be independent of the used tool chain:
For example, in "board/tqc/tqm8xx/u-boot.lds" we arrange to have the environment located in one of the "small" NOR flash sectors:
.... 53 .text : 54 { 55 /* WARNING - the following is hand-optimized to fit within */ 56 /* the sector layout of our flash chips! XXX FIXME XXX */ 57 58 arch/powerpc/cpu/mpc8xx/start.o (.text) 59 arch/powerpc/cpu/mpc8xx/traps.o (.text) 60 common/dlmalloc.o (.text) 61 arch/powerpc/lib/ppcstring.o (.text) 62 lib/vsprintf.o (.text) 63 lib/crc32.o (.text) 64 lib/zlib.o (.text) 65 arch/powerpc/lib/cache.o (.text) 66 67 . = DEFINED(env_offset) ? env_offset : .; 68 common/env_embedded.o (.ppcenv) 69 70 *(.text) 71 *(.got1) ....
That means, the linker script pulls in certain object files directly. Before, when linking with libraries, this was no problem, as the linker would pull only (so far) unresolved symbols from the libraries specified on the command line. Now, we include these individual object files through the linker script, and then again when specifying the "library" objects on the command line - which necessarily results in "multiple definition" errors.
Are you sure of this? From http://sourceware.org/binutils/docs-2.20/ld/Input-Section-Basics.html#Input-Section-Basics, specifying a file name in the linker file *and* on the command line should not lead to a double inclusion of the object file:
"When you use a file name which is not an `archive:file' specifier and does not contain any wild card characters, the linker will first see if you also specified the file name on the linker command line or in an INPUT command. If you did not, the linker will attempt to open the file as an input file, as though it appeared on the command line."
Unfortunately I don't know how to solve this yet. Does anybody know of a way how to manually arrange the objects (or symbols) in the linked image?
Best regards,
Wolfgang Denk
Amicalement,
Dear Albert ARIBAUD,
In message 4CE5A3F1.50304@free.fr you wrote:
58 arch/powerpc/cpu/mpc8xx/start.o (.text) 59 arch/powerpc/cpu/mpc8xx/traps.o (.text) 60 common/dlmalloc.o (.text) 61 arch/powerpc/lib/ppcstring.o (.text) 62 lib/vsprintf.o (.text) 63 lib/crc32.o (.text) 64 lib/zlib.o (.text) 65 arch/powerpc/lib/cache.o (.text) 66 67 . = DEFINED(env_offset) ? env_offset : .; 68 common/env_embedded.o (.ppcenv)
...
Are you sure of this? From http://sourceware.org/binutils/docs-2.20/ld/Input-Section-Basics.html#Input-Section-Basics, specifying a file name in the linker file *and* on the command line should not lead to a double inclusion of the object file:
I'm sure that I see the errors.
I see two possible reasons: 1) whay you describe is a new feature in binutils 2.20; I'm currently using 2.17.50 (with ELDk 4.2); or 2) the linker does not realize it because it's actually different file names: for example, vsprintf() gets included in the linker script directly through lib/vsprintf.o, and throught he command line as lib/libgeneric.o ==> two different file names.
Best regards,
Wolfgang Denk
Le 18/11/2010 23:33, Wolfgang Denk a écrit :
Dear Albert ARIBAUD,
In message4CE5A3F1.50304@free.fr you wrote:
58 arch/powerpc/cpu/mpc8xx/start.o (.text) 59 arch/powerpc/cpu/mpc8xx/traps.o (.text) 60 common/dlmalloc.o (.text) 61 arch/powerpc/lib/ppcstring.o (.text) 62 lib/vsprintf.o (.text) 63 lib/crc32.o (.text) 64 lib/zlib.o (.text) 65 arch/powerpc/lib/cache.o (.text) 66 67 . = DEFINED(env_offset) ? env_offset : .; 68 common/env_embedded.o (.ppcenv)
....
Are you sure of this? From http://sourceware.org/binutils/docs-2.20/ld/Input-Section-Basics.html#Input-Section-Basics, specifying a file name in the linker file *and* on the command line should not lead to a double inclusion of the object file:
I'm sure that I see the errors.
I see two possible reasons: 1) whay you describe is a new feature in binutils 2.20; I'm currently using 2.17.50 (with ELDk 4.2); or 2) the linker does not realize it because it's actually different file names: for example, vsprintf() gets included in the linker script directly through lib/vsprintf.o, and throught he command line as lib/libgeneric.o ==> two different file names.
Most probably 2); mentioning a file in the linker script either with or without mentioning it on the command line has certainly been done for some time, so I doubt the feature is new; and certainly the doc is about files, not symbols in different files.
And, to get back to possible solutions, I don't know that the linker can map selected symbols onto specific regions; it can only place whole object files.
The simplest, though not cleanest, way I can think of is to put conditionals to not compile vsprintf() in lib/generic, and set those conditions from the board config file -- and same for anything else. Ugly, but it will work.
A second solution, a bit more intrusive, would be to split lib/generic in two files; a "small" one which could be mapped in the small area, and the rest, which would map with the rest of the image.
Best regards,
Wolfgang Denk
Amicalement,
Dear Albert ARIBAUD,
In message 4CE61AD5.50900@free.fr you wrote:
Most probably 2); mentioning a file in the linker script either with or without mentioning it on the command line has certainly been done for some time, so I doubt the feature is new; and certainly the doc is about files, not symbols in different files.
There seems to be a (here significant) difference between object files on the command line and libraries (which appear to be handled like a mere collection of object files).
And, to get back to possible solutions, I don't know that the linker can map selected symbols onto specific regions; it can only place whole object files.
There must be a way ;-)
The simplest, though not cleanest, way I can think of is to put conditionals to not compile vsprintf() in lib/generic, and set those conditions from the board config file -- and same for anything else. Ugly, but it will work.
A second solution, a bit more intrusive, would be to split lib/generic in two files; a "small" one which could be mapped in the small area, and the rest, which would map with the rest of the image.
That doesn't scale - the set is sifferent on a per-board base, which would result in a terrible mess.
Best regards,
Wolfgang Denk
On Friday, November 19, 2010 03:03:54 Wolfgang Denk wrote:
Albert ARIBAUD wrote:
Most probably 2); mentioning a file in the linker script either with or without mentioning it on the command line has certainly been done for some time, so I doubt the feature is new; and certainly the doc is about files, not symbols in different files.
There seems to be a (here significant) difference between object files on the command line and libraries (which appear to be handled like a mere collection of object files).
the difference is that the linker wont bother looking at the duplicated objects in the archives. from the linker's perspective though, we now have to completely independent objects. the combined one specified on the command line and the split up ones in the linker script.
one possible way to fix boards is to stop specifying sub-objects in the linker script and only specify the combined ones. so in board/tqc/tqm8xx/u-boot.lds, drop the split objects like lib/zlib.o in favor of the combined one like lib/libgeneric.o. this might not work for everyone since the combined object sizes can be a bit large. if everyone was using -ffunction-sections/-fdata- sections
this however wont work for common/env_embedded.o since it is merged common/libcommon.o. so to fix that, we'll need to not merge env_embedded.o into libcommon.o. like in the patch below. -mike
diff --git a/common/Makefile b/common/Makefile index e0db382..d38aa7b 100644 --- a/common/Makefile +++ b/common/Makefile @@ -52,10 +52,10 @@ COBJS-y += cmd_version.o COBJS-y += env_common.o COBJS-$(CONFIG_ENV_IS_IN_DATAFLASH) += env_dataflash.o COBJS-$(CONFIG_ENV_IS_IN_EEPROM) += env_eeprom.o -COBJS-$(CONFIG_ENV_IS_EMBEDDED) += env_embedded.o -COBJS-$(CONFIG_ENV_IS_IN_EEPROM) += env_embedded.o -COBJS-$(CONFIG_ENV_IS_IN_FLASH) += env_embedded.o -COBJS-$(CONFIG_ENV_IS_IN_NVRAM) += env_embedded.o +XOBJS-$(CONFIG_ENV_IS_EMBEDDED) += env_embedded.o +XOBJS-$(CONFIG_ENV_IS_IN_EEPROM) += env_embedded.o +XOBJS-$(CONFIG_ENV_IS_IN_FLASH) += env_embedded.o +XOBJS-$(CONFIG_ENV_IS_IN_NVRAM) += env_embedded.o COBJS-$(CONFIG_ENV_IS_IN_FLASH) += env_flash.o COBJS-$(CONFIG_ENV_IS_IN_MG_DISK) += env_mgdisk.o COBJS-$(CONFIG_ENV_IS_IN_MMC) += env_mmc.o @@ -174,7 +174,7 @@ OBJS := $(addprefix $(obj),$(AOBJS) $(COBJS))
CPPFLAGS += -I..
-all: $(LIB) $(AOBJS) +all: $(LIB) $(AOBJS) $(XOBJS-y)
$(LIB): $(obj).depend $(OBJS) $(call cmd_link_o_target, $(OBJS))
Dear Mike Frysinger,
In message 201011191908.00162.vapier@gentoo.org you wrote:
the difference is that the linker wont bother looking at the duplicated objects in the archives. from the linker's perspective though, we now have to completely independent objects. the combined one specified on the command line and the split up ones in the linker script.
Right.
one possible way to fix boards is to stop specifying sub-objects in the linker script and only specify the combined ones. so in board/tqc/tqm8xx/u-boot.lds, drop the split objects like lib/zlib.o in favor of the combined one like lib/libgeneric.o. this might not work for everyone since the combined object
It doesn't work as we cannot fine-adjust the size of the combined objects as it's needed for at least coarse adjustment to the available flash sector sizes.
sizes can be a bit large. if everyone was using -ffunction-sections/-fdata- sections
? Could you please complete that sentence?
this however wont work for common/env_embedded.o since it is merged common/libcommon.o. so to fix that, we'll need to not merge env_embedded.o into libcommon.o. like in the patch below. -mike
diff --git a/common/Makefile b/common/Makefile index e0db382..d38aa7b 100644 --- a/common/Makefile +++ b/common/Makefile @@ -52,10 +52,10 @@ COBJS-y += cmd_version.o COBJS-y += env_common.o COBJS-$(CONFIG_ENV_IS_IN_DATAFLASH) += env_dataflash.o COBJS-$(CONFIG_ENV_IS_IN_EEPROM) += env_eeprom.o -COBJS-$(CONFIG_ENV_IS_EMBEDDED) += env_embedded.o -COBJS-$(CONFIG_ENV_IS_IN_EEPROM) += env_embedded.o -COBJS-$(CONFIG_ENV_IS_IN_FLASH) += env_embedded.o -COBJS-$(CONFIG_ENV_IS_IN_NVRAM) += env_embedded.o +XOBJS-$(CONFIG_ENV_IS_EMBEDDED) += env_embedded.o +XOBJS-$(CONFIG_ENV_IS_IN_EEPROM) += env_embedded.o +XOBJS-$(CONFIG_ENV_IS_IN_FLASH) += env_embedded.o +XOBJS-$(CONFIG_ENV_IS_IN_NVRAM) += env_embedded.o COBJS-$(CONFIG_ENV_IS_IN_FLASH) += env_flash.o COBJS-$(CONFIG_ENV_IS_IN_MG_DISK) += env_mgdisk.o COBJS-$(CONFIG_ENV_IS_IN_MMC) += env_mmc.o
Is this not too much? We have embedded environment only in the case of NOR flash, so the extra handling should only be done for CONFIG_ENV_IS_EMBEDDED ?
Best regards,
Wolfgang Denk
Le 20/11/2010 09:38, Wolfgang Denk a écrit :
Dear Mike Frysinger,
In message201011191908.00162.vapier@gentoo.org you wrote:
sizes can be a bit large. if everyone was using -ffunction-sections/-fdata- sections
? Could you please complete that sentence?
I believe the idea is that with these options, the build produces not one single input section for all code and one single input section for all data of a given object file, but one input section per function and one input section per variable, thus allowing the linker file to fin-grain-tune the content of the isolated sector(s), specifying exactly which function or (initialized) data would go in there.
Amicalement,
On Saturday, November 20, 2010 03:38:44 Wolfgang Denk wrote:
Mike Frysinger wrote:
one possible way to fix boards is to stop specifying sub-objects in the linker script and only specify the combined ones. so in board/tqc/tqm8xx/u-boot.lds, drop the split objects like lib/zlib.o in favor of the combined one like lib/libgeneric.o. this might not work for everyone since the combined object
It doesn't work as we cannot fine-adjust the size of the combined objects as it's needed for at least coarse adjustment to the available flash sector sizes.
sizes can be a bit large. if everyone was using -ffunction-sections/-fdata- sections
? Could you please complete that sentence?
if everyone used these options, then the linker script would get fine grained control as people could still specify the combined object, but only pull in specific sections. so the linker script could do in the leading space: lib/libgeneric.o (.text.crc32 .text.gunzip .text........) and then in the normal space after the env, do: lib/libgeneric.o (.text*) since the linker has already placed the specific sections earlier, the glob wont pull them in again.
while these options normally imply the end goal of --gc-sections, using that flag isnt a requirement. as long as the linker scripts specify things like ".text*" instead of just ".text", then they should work fine. and people dont have to worry about the linker discarding unreferenced sections (such as reset vectors or whatever). at least not today ... this really should get fixed across the board.
this however wont work for common/env_embedded.o since it is merged common/libcommon.o. so to fix that, we'll need to not merge env_embedded.o into libcommon.o. like in the patch below.
diff --git a/common/Makefile b/common/Makefile index e0db382..d38aa7b 100644 --- a/common/Makefile +++ b/common/Makefile @@ -52,10 +52,10 @@ COBJS-y += cmd_version.o
COBJS-y += env_common.o COBJS-$(CONFIG_ENV_IS_IN_DATAFLASH) += env_dataflash.o COBJS-$(CONFIG_ENV_IS_IN_EEPROM) += env_eeprom.o
-COBJS-$(CONFIG_ENV_IS_EMBEDDED) += env_embedded.o -COBJS-$(CONFIG_ENV_IS_IN_EEPROM) += env_embedded.o -COBJS-$(CONFIG_ENV_IS_IN_FLASH) += env_embedded.o -COBJS-$(CONFIG_ENV_IS_IN_NVRAM) += env_embedded.o +XOBJS-$(CONFIG_ENV_IS_EMBEDDED) += env_embedded.o +XOBJS-$(CONFIG_ENV_IS_IN_EEPROM) += env_embedded.o +XOBJS-$(CONFIG_ENV_IS_IN_FLASH) += env_embedded.o +XOBJS-$(CONFIG_ENV_IS_IN_NVRAM) += env_embedded.o
COBJS-$(CONFIG_ENV_IS_IN_FLASH) += env_flash.o COBJS-$(CONFIG_ENV_IS_IN_MG_DISK) += env_mgdisk.o COBJS-$(CONFIG_ENV_IS_IN_MMC) += env_mmc.o
Is this not too much? We have embedded environment only in the case of NOR flash, so the extra handling should only be done for CONFIG_ENV_IS_EMBEDDED ?
dont really know what you're referring to ... this patch works on my Blackfin boards. however, it doesnt really matter, as another option would be to simply stick the env into its own sections. two ways to accomplish this:
(1) if we use -ffunction-sections/-fdata-sections for everyone and we punt the __PPCENV__ and __PPCTEXT__ hacks, in the linker script, you could do: common/libcommon.o (.data.environment .data.redundand_environment .data.env_size)
(2) or tweak/extend the __PPCENV__ and __PPCTEXT__ hacks to manually place the vars into more specific sections rather than just ".text". then the linker script would do something like: common/libcommon.o (.text.environment .text.redundand_environment .text.env_size)
obviously i'd prefer (1) since the gcc attribute usage in env_embedded.c makes me want to barf. -mike
On 2010-11-19 07:36:05, Albert ARIBAUD wrote:
Le 18/11/2010 23:33, Wolfgang Denk a écrit :
I see two possible reasons: 1) whay you describe is a new feature in binutils 2.20; I'm currently using 2.17.50 (with ELDk 4.2); or 2) the linker does not realize it because it's actually different file names: for example, vsprintf() gets included in the linker script directly through lib/vsprintf.o, and throught he command line as lib/libgeneric.o ==> two different file names.
Most probably 2); mentioning a file in the linker script either with or without mentioning it on the command line has certainly been done for some time, so I doubt the feature is new; and certainly the doc is about files, not symbols in different files.
Sounds right, reason 2) completely makes sense.
And, to get back to possible solutions, I don't know that the linker can map selected symbols onto specific regions; it can only place whole object files.
Could we place the object files in distinct sections, and then map these sections into specific regions?
The simplest, though not cleanest, way I can think of is to put conditionals to not compile vsprintf() in lib/generic, and set those conditions from the board config file -- and same for anything else. Ugly, but it will work.
Perhaps an even simpler solution would be to go back to archive libraries and use ld --whole-archives. It would leave object names intact and thus avoid double-inclusions.
A second solution, a bit more intrusive, would be to split lib/generic in two files; a "small" one which could be mapped in the small area, and the rest, which would map with the rest of the image.
Perhaps section declarations could be used to achieve this without having to split the files? It seems challenging to come up with a way to do this to optimally fill a given sector, though.
Regards,
Dear Wolfgang,
On 2010-11-18 22:44:48, Wolfgang Denk wrote:
Unfortunately I have not been able to reproduce these errors with the toolchain I am using (gcc 4.4.5 and binutils 2.20.1.20100303, based on emdebian squeeze packages). Can you please point me to the toolchain you are using?
Are you sure this doesn't happen with your tool chain?
Weird, I tried the FPS860L configuration again and now I can see these errors with my toolchain. Not sure what I did wrong the first time around.
I found out why this happens, and I think the effect should be independent of the used tool chain:
Great! I have been quite busy for the last couple days, sorry I hadn't been able to check it out yet.
Unfortunately I don't know how to solve this yet. Does anybody know of a way how to manually arrange the objects (or symbols) in the linked image?
Sounds difficult once object files have been linked into a new partial object... I do not know if it would be practical to use sections instead, it depends what needs to be achieved.
It looks like the purpose is to optimally fill a flash sector with definitions, is this accurate? Why is this needed? Beside the obvious (reset vectors, startup code), is there any reason to prefer any given definition to go into the sector being filled?
Regards,
Dear Sebastien Carlier,
In message sebastien.carlier@1e724f1c01c015f817d5e33b57e7134d4468dbcc you wrote:
It looks like the purpose is to optimally fill a flash sector with definitions, is this accurate? Why is this needed? Beside the obvious
Correct.
(reset vectors, startup code), is there any reason to prefer any given definition to go into the sector being filled?
Well, we want to squeeze as many code into the first sectores, to minimize the unused space. So far this was trivial, as I just could pick object files of suitable size. Now we have to come up with a new solution.
Best regards,
Wolfgang Denk
Dear Wolfgang,
On 2010-11-19 09:08:33, Wolfgang Denk wrote:
In message sebastien.carlier@1e724f1c01c015f817d5e33b57e7134d4468dbcc you wrote:
It looks like the purpose is to optimally fill a flash sector with definitions, is this accurate? Why is this needed? Beside the obvious
Correct.
(reset vectors, startup code), is there any reason to prefer any given definition to go into the sector being filled?
Well, we want to squeeze as many code into the first sectores, to minimize the unused space.
I am still not getting why the code needs to be split this way, rather than being a continuous segment followed by an environment sector. Whether the environment sector is in the middle of the binary or immediately after the binary does not make a difference (does it?), so the motivation must be something else...
So far this was trivial, as I just could pick object files of suitable size. Now we have to come up with a new solution.
Sounds like you enjoyed solving knapsack problems :-)
Regards,
Dear Sebastien Carlier,
In message sebastien.carlier@f67ce90ecc8846695b88fb9ac74f99d56979b90a you wrote:
I am still not getting why the code needs to be split this way, rather than being a continuous segment followed by an environment sector. Whether the environment sector is in the middle of the binary or immediately after the binary does not make a difference (does it?), so the motivation must be something else...
The used flash chips are so-called bootom boot sector types; using two chips in 16 bit config in parallel (to get a 32 bit bus) we see this flash layout:
Sector Start Addresses: 40000000 RO 40008000 RO 4000C000 RO 40010000 RO 40020000 RO 40040000 RO 40060000 E 40080000 E 400A0000 E 400C0000 E 400E0000 E 40100000 E 40120000 E 40140000 E 40160000 E 40180000 E 401A0000 E 401C0000 E 401E0000 E 40200000 E 40220000 E 40240000 E 40260000 E 40280000 E 402A0000 E 402C0000 E 402E0000 E 40300000 E 40320000 E 40340000 E 40360000 E 40380000 E 403A0000 E 403C0000 E 403E0000 E
So erase block sizes are 32 k, 16 k, 16 k, 64 k, 128 k, 128 k, 128 k, ...
With a normal configuration, U-Boot code wouild occupy all the small sectors, and we would have to waste two of the 128 kB blocks for environment plus redundant copy.
It makes a lot sense to me to reserve a "gap" in the U-Boot image and put the environment instead into the two 16 kB sectors starting at 40008000 and 4000C000.
The linker script squeezes as many as possible objects into the first 32 kB ssector, then creates a gap for the environment, and ten continues to place the remaining objects starting at offset 40010000.
That's what we call "embedded environment", because it sits right in the middle of the U-Boot image.
Best regards,
Wolfgang Denk
Le 19/11/2010 12:11, Wolfgang Denk a écrit :
Dear Sebastien Carlier,
In messagesebastien.carlier@f67ce90ecc8846695b88fb9ac74f99d56979b90a you wrote:
I am still not getting why the code needs to be split this way, rather than being a continuous segment followed by an environment sector. Whether the environment sector is in the middle of the binary or immediately after the binary does not make a difference (does it?), so the motivation must be something else...
The used flash chips are so-called bootom boot sector types; using two chips in 16 bit config in parallel (to get a 32 bit bus) we see this flash layout:
Sector Start Addresses: 40000000 RO 40008000 RO 4000C000 RO 40010000 RO 40020000 RO 40040000 RO 40060000 E 40080000 E 400A0000 E 400C0000 E 400E0000 E 40100000 E 40120000 E 40140000 E 40160000 E 40180000 E 401A0000 E 401C0000 E 401E0000 E 40200000 E 40220000 E 40240000 E 40260000 E 40280000 E 402A0000 E 402C0000 E 402E0000 E 40300000 E 40320000 E 40340000 E 40360000 E 40380000 E 403A0000 E 403C0000 E 403E0000 E
So erase block sizes are 32 k, 16 k, 16 k, 64 k, 128 k, 128 k, 128 k, ...
With a normal configuration, U-Boot code wouild occupy all the small sectors, and we would have to waste two of the 128 kB blocks for environment plus redundant copy.
It makes a lot sense to me to reserve a "gap" in the U-Boot image and put the environment instead into the two 16 kB sectors starting at 40008000 and 4000C000.
The linker script squeezes as many as possible objects into the first 32 kB ssector, then creates a gap for the environment, and ten continues to place the remaining objects starting at offset 40010000.
That's what we call "embedded environment", because it sits right in the middle of the U-Boot image.
There is a variant of this problem with many ARM boards, those based on Marvell SoCs for instance, which have a start address at 0xFFFF0000 -- that's a 64K block the usage of which we want to maximize.
I had a general solution to this by, in summary, building a linear u-boot, then splitting the binary when flashing, and have the copy loop in the startup stitch back the parts. However, this solution did not work well with relocation, and may not necessarily be applicable to non-ARM archs. However, now that we have a (mostly) stabilized relocation mechanism, I'll dig again into this solution.
Best regards,
Wolfgang Denk
Amicalement,
Dear Albert ARIBAUD,
In message 4CE66215.2030103@free.fr you wrote:
There is a variant of this problem with many ARM boards, those based on Marvell SoCs for instance, which have a start address at 0xFFFF0000 -- that's a 64K block the usage of which we want to maximize.
Yes, that's basicly a simialr problem.
I had a general solution to this by, in summary, building a linear u-boot, then splitting the binary when flashing, and have the copy loop in the startup stitch back the parts. However, this solution did not work well with relocation, and may not necessarily be applicable to non-ARM archs. However, now that we have a (mostly) stabilized relocation mechanism, I'll dig again into this solution.
The problem is that we're now linked for running in flash, so the linker should be the tool that performs the location of code into the output image.
Best regards,
Wolfgang Denk
Le 19/11/2010 12:48, Wolfgang Denk a écrit :
Dear Albert ARIBAUD,
In message4CE66215.2030103@free.fr you wrote:
There is a variant of this problem with many ARM boards, those based on Marvell SoCs for instance, which have a start address at 0xFFFF0000 -- that's a 64K block the usage of which we want to maximize.
Yes, that's basicly a simialr problem.
I had a general solution to this by, in summary, building a linear u-boot, then splitting the binary when flashing, and have the copy loop in the startup stitch back the parts. However, this solution did not work well with relocation, and may not necessarily be applicable to non-ARM archs. However, now that we have a (mostly) stabilized relocation mechanism, I'll dig again into this solution.
The problem is that we're now linked for running in flash, so the linker should be the tool that performs the location of code into the output image.
Indeed.
But then, there's where your code was linked for, where it will relocate to... and where it actually runs.
After all, ELF relocation would work equally well whatever the link location.
Yes, I know that running code somewhere else than where it was linked for may be difficult. But not necessarily impossible, and I *think* I can find a way.
Best regards,
Wolfgang Denk
Amicalement,
Dear Wolfgang,
On 2010-11-19 12:11:12, Wolfgang Denk wrote:
In message sebastien.carlier@f67ce90ecc8846695b88fb9ac74f99d56979b90a you wrote:
The used flash chips are so-called bootom boot sector types; using two chips in 16 bit config in parallel (to get a 32 bit bus) we see this flash layout:
Sector Start Addresses: 40000000 RO 40008000 RO 4000C000 RO 40010000 RO 40020000 RO 40040000 RO 40060000 E 40080000 E 400A0000 E 400C0000 E 400E0000 E 40100000 E 40120000 E 40140000 E 40160000 E 40180000 E 401A0000 E 401C0000 E 401E0000 E 40200000 E 40220000 E 40240000 E 40260000 E 40280000 E 402A0000 E 402C0000 E 402E0000 E 40300000 E 40320000 E 40340000 E 40360000 E 40380000 E 403A0000 E 403C0000 E 403E0000 E
So erase block sizes are 32 k, 16 k, 16 k, 64 k, 128 k, 128 k, 128 k, ...
Oh, I see. I wasn't aware that some flash chips had non-uniform sector sizes. It makes perfect sense not to waste much of a larger sector to store the environment. Thank you very much for clarifying!
The linker script squeezes as many as possible objects into the first 32 kB ssector, then creates a gap for the environment, and ten continues to place the remaining objects starting at offset 40010000.
Is it not possible to tell the linker to place a made-up 32 kB symbol within the text section at address 0x40008000? I am not familiar enough with ld to tell whether there are restrictions for setting the absolute address of a symbol that would disallow it in this case.
Regards,
Le 19/11/2010 13:33, Sebastien Carlier a écrit :
Dear Wolfgang,
On 2010-11-19 12:11:12, Wolfgang Denk wrote:
In messagesebastien.carlier@f67ce90ecc8846695b88fb9ac74f99d56979b90a you wrote:
The used flash chips are so-called bootom boot sector types; using two chips in 16 bit config in parallel (to get a 32 bit bus) we see this flash layout:
Sector Start Addresses: 40000000 RO 40008000 RO 4000C000 RO 40010000 RO 40020000 RO 40040000 RO 40060000 E 40080000 E 400A0000 E 400C0000 E 400E0000 E 40100000 E 40120000 E 40140000 E 40160000 E 40180000 E 401A0000 E 401C0000 E 401E0000 E 40200000 E 40220000 E 40240000 E 40260000 E 40280000 E 402A0000 E 402C0000 E 402E0000 E 40300000 E 40320000 E 40340000 E 40360000 E 40380000 E 403A0000 E 403C0000 E 403E0000 E
So erase block sizes are 32 k, 16 k, 16 k, 64 k, 128 k, 128 k, 128 k, ...
Oh, I see. I wasn't aware that some flash chips had non-uniform sector sizes. It makes perfect sense not to waste much of a larger sector to store the environment. Thank you very much for clarifying!
The linker script squeezes as many as possible objects into the first 32 kB ssector, then creates a gap for the environment, and ten continues to place the remaining objects starting at offset 40010000.
Is it not possible to tell the linker to place a made-up 32 kB symbol within the text section at address 0x40008000? I am not familiar enough with ld to tell whether there are restrictions for setting the absolute address of a symbol that would disallow it in this case.
Regards,
You can force a symbol to reside at a given offset, but that will not make the linker "skip" that symbol when filling the output section, if that's what you meant.
If you read up the binutils doc, you'll see that ld fills output sections based on a "location pointer" (the "dot") that simply moves on with each input section added -- no skipping, and no jumping from one region to another either.
Amicalement,
Dear Albert,
On 2010-11-19 13:38:00, Albert ARIBAUD wrote:
Le 19/11/2010 13:33, Sebastien Carlier a écrit :
Is it not possible to tell the linker to place a made-up 32 kB symbol within the text section at address 0x40008000? I am not familiar enough with ld to tell whether there are restrictions for setting the absolute address of a symbol that would disallow it in this case.
You can force a symbol to reside at a given offset, but that will not make the linker "skip" that symbol when filling the output section, if that's what you meant.
Yes, I was hoping the linker would first allocate space for absolute-address symbols and then fill the gaps with the remaining symbols in whatever order.
If you read up the binutils doc, you'll see that ld fills output sections based on a "location pointer" (the "dot") that simply moves on with each input section added -- no skipping, and no jumping from one region to another either.
I see, thank you for pointing this out. This specific behavior actually seems quite essential to the interpretation of linker scripts, so there is probably no hope for any change there.
I very much like your idea of splitting the binary when flashing and recomposing it into RAM during copying just before relocation, it looks very flexible and elegant. A separate solution is still needed for running from flash... apart from switching back to archive libraries and using --whole-archive, I am out of ideas at the moment.
Regards,
Dear Albert,
On 2010-11-19 13:38:00, Albert ARIBAUD wrote:
Le 19/11/2010 13:33, Sebastien Carlier a écrit :
Is it not possible to tell the linker to place a made-up 32 kB symbol within the text section at address 0x40008000? I am not familiar enough with ld to tell whether there are restrictions for setting the absolute address of a symbol that would disallow it in this case.
You can force a symbol to reside at a given offset, but that will not make the linker "skip" that symbol when filling the output section, if that's what you meant.
Yes, I was hoping the linker would first allocate space for absolute-address symbols and then fill the gaps with the remaining symbols in whatever order.
If you read up the binutils doc, you'll see that ld fills output sections based on a "location pointer" (the "dot") that simply moves on with each input section added -- no skipping, and no jumping from one region to another either.
I see, thank you for pointing this out. This specific behavior actually seems quite essential to the interpretation of linker scripts, so there is probably no hope for any change there.
Have you tried something in the line of:
/* Memory Definitions */
MEMORY { CODE (rx) : ORIGIN = 0x00000000, LENGTH = 0x0007E000 DATA (rw) : ORIGIN = 0x40000000, LENGTH = 0x00007A00 ENET (rw) : ORIGIN = 0x7FE00000, LENGTH = 0x00004000 }
/* Section Definitions */
SECTIONS {
/* first section is .text which is used for code */
.text : { *startup2300.o (.text) /* Startup code */ *basicio.o (.text) /* basic I/O */ *(.text) /* remaining code */
*(.glue_7t) *(.glue_7)
} >CODE =0
. = ALIGN(4);
...
*maybe* one can define several areas for CODE in the MEMORY section?
Best Regards, Reinhard
Le 19/11/2010 14:07, Reinhard Meyer a écrit :
Dear Albert,
On 2010-11-19 13:38:00, Albert ARIBAUD wrote:
Le 19/11/2010 13:33, Sebastien Carlier a écrit :
Is it not possible to tell the linker to place a made-up 32 kB symbol within the text section at address 0x40008000? I am not familiar enough with ld to tell whether there are restrictions for setting the absolute address of a symbol that would disallow it in this case.
You can force a symbol to reside at a given offset, but that will not make the linker "skip" that symbol when filling the output section, if that's what you meant.
Yes, I was hoping the linker would first allocate space for absolute-address symbols and then fill the gaps with the remaining symbols in whatever order.
If you read up the binutils doc, you'll see that ld fills output sections based on a "location pointer" (the "dot") that simply moves on with each input section added -- no skipping, and no jumping from one region to another either.
I see, thank you for pointing this out. This specific behavior actually seems quite essential to the interpretation of linker scripts, so there is probably no hope for any change there.
Have you tried something in the line of:
/* Memory Definitions */
MEMORY { CODE (rx) : ORIGIN = 0x00000000, LENGTH = 0x0007E000 DATA (rw) : ORIGIN = 0x40000000, LENGTH = 0x00007A00 ENET (rw) : ORIGIN = 0x7FE00000, LENGTH = 0x00004000 }
/* Section Definitions */
SECTIONS {
/* first section is .text which is used for code */
.text : { *startup2300.o (.text) /* Startup code */ *basicio.o (.text) /* basic I/O */ *(.text) /* remaining code */
*(.glue_7t) *(.glue_7)}>CODE =0
. = ALIGN(4);
...
Those regions would most probably inflate the .bin because of the gap between the various MEMORY areas.
*maybe* one can define several areas for CODE in the MEMORY section?
Afraid not. :/
Amicalement,
Dear Reinhard Meyer,
In message 4CE676A6.10205@emk-elektronik.de you wrote:
Have you tried something in the line of:
/* Memory Definitions */
MEMORY { CODE (rx) : ORIGIN 0x00000000, LENGTH 0x0007E000 DATA (rw) : ORIGIN 0x40000000, LENGTH 0x00007A00 ENET (rw) : ORIGIN 0x7FE00000, LENGTH 0x00004000 }
I've looked into that, but didn't find a way to make it do what needs to be done,
*maybe* one can define several areas for CODE in the MEMORY section?
I don't think so. The "ld" documentation says: "Each memory region must have a distinct name within the `MEMORY' command."
Best regards,
Wolfgang Denk
Dear Sebastien Carlier,
In message sebastien.carlier@9400084bb093b10e93ff65be513a8043def9b8e1 you wrote:
Is it not possible to tell the linker to place a made-up 32 kB symbol within the text section at address 0x40008000? I am not familiar enough with ld to tell whether there are restrictions for setting the absolute address of a symbol that would disallow it in this case.
I don't know such a method. We would not even have to make up any symbols - if we could forst the Linker to place "environment" at 0x40008000 and "redundand_environment" at 0x4000c000 everything would be perfect. Before this patch, this was what we had:
... 0x40005ebc inflateInit2_ 0x400058f4 inflate_table arch/powerpc/lib/cache.o(.text) .text 0x40007c20 0x64 arch/powerpc/lib/cache.o 0x40007c20 flush_cache 0x00008000 . = DEFINED (env_offset)?env_offset:. *fill* 0x40007c84 0x37c 00 common/env_embedded.o(.ppcenv) .ppcenv 0x40008000 0x8000 common/env_embedded.o 0x40008000 environment 0x4000c000 redundand_environment *(.text) .text 0x40010000 0x4 common/env_embedded.o 0x40010000 env_size .text 0x40010004 0x0 lib/libgeneric.a(ctype.o) .text 0x40010004 0x10c lib/libgeneric.a(div64.o) 0x40010004 __div64_32 ...
But I don't know of a way to enforce this...
Best regards,
Wolfgang Denk
On Friday, November 19, 2010 02:50:37 Sebastien Carlier wrote:
It looks like the purpose is to optimally fill a flash sector with definitions, is this accurate? Why is this needed? Beside the obvious (reset vectors, startup code), is there any reason to prefer any given definition to go into the sector being filled?
i havent looked at this particular case, but often it's because we need to carve out a sector for an embedded env and the linker script syntax isnt good enough to say "start filling this section and once it's filled, start filling this other one". that'd be awesome. -mike
On Monday, November 15, 2010 03:09:50 Sebastien Carlier wrote:
On 2010-11-15 08:51:29, Wolfgang Denk wrote:
In message 20101110080708.GA8145@safe.home.local you wrote:
Good suggestion, done in v3:
I have to admit that I lost a bit of overview of the current state of this work. My understanding is that you are preparing a new version (V4 ?) of this patch?
If yes, do you have any estimates when this will be available?
I just uploaded the revised patch here:
http://www.denx.de/wiki/pub/U-Boot/TooBigPatches/0001-Switch-from-
archive-
libraries-to-partial-linking-v4.patch
Version 4: Bring in Linux comment for cmd_link_o_target. Fix drivers/qe/Makefile to build libqe.o, not qe.o.
I pulled the latest changes before making the patch and there was no conflict, but please let me know if you see anything wrong with it.
Tested-by: Mike Frysinger vapier@gentoo.org (Blackfin boards) -mike
On Monday, November 08, 2010 17:04:32 Sebastien Carlier wrote:
This commit changes all Makefiles to use partial linking (ld -r) instead of creating library archives, which forces all symbols to participate in linking, allowing non-weak symbols to override weak symbols as intended. This approach is also used by Linux, from which the gmake function cmd_link_o_target (added at the end of config.mk and used in all Makefiles) is inspired.
linux takes it a step further ... it partially links everything into one .o before turning that into the final ELF. why dont we do the same (partially link everything into u-boot.o and then just do u-boot.o->u-boot) ? it should allow us to drop the start/end group flags in the process. -mike
On Mon, Nov 8, 2010 at 4:04 PM, Sebastien Carlier sebastien.carlier@gmail.com wrote:
NOTE: This does not include the actual patch as it is too large for the mailing list (418 kB).
Before this commit, weak symbols were not overridden by non-weak symbols found in archive libraries when linking with recent versions of binutils. As stated in the System V ABI, "the link editor does not extract archive members to resolve undefined weak symbols".
This commit changes all Makefiles to use partial linking (ld -r) instead of creating library archives, which forces all symbols to participate in linking, allowing non-weak symbols to override weak symbols as intended. This approach is also used by Linux, from which the gmake function cmd_link_o_target (added at the end of config.mk and used in all Makefiles) is inspired.
The name of each former library archive is preserved except for extensions which change from ".a" to ".o". This commit updates references accordingly where needed, in particular in some linker scripts.
This commit reveals board configurations that exclude some module but not all of its dependencies; for example, disabling CMD_NET but not CMD_NFS results in undefined symbols at link time.
Signed-off-by: Sebastien Carlier sebastien.carlier@gmail.com
git-bisect tells me that your patch (or whatever version of it was actually applied) causes this linker warning:
powerpc-linux-gnu-ld: Warning: lib_powerpc/fpu/libpostpowerpcfpu.o uses hard float, libpost.o uses soft float
See this thread for details: http://lists.denx.de/pipermail/u-boot/2011-January/085811.html
I have no idea how to fix this.
On Jan 24, 2011, at 2:54 PM, Timur Tabi wrote:
On Mon, Nov 8, 2010 at 4:04 PM, Sebastien Carlier sebastien.carlier@gmail.com wrote:
NOTE: This does not include the actual patch as it is too large for the mailing list (418 kB).
Before this commit, weak symbols were not overridden by non-weak symbols found in archive libraries when linking with recent versions of binutils. As stated in the System V ABI, "the link editor does not extract archive members to resolve undefined weak symbols".
This commit changes all Makefiles to use partial linking (ld -r) instead of creating library archives, which forces all symbols to participate in linking, allowing non-weak symbols to override weak symbols as intended. This approach is also used by Linux, from which the gmake function cmd_link_o_target (added at the end of config.mk and used in all Makefiles) is inspired.
The name of each former library archive is preserved except for extensions which change from ".a" to ".o". This commit updates references accordingly where needed, in particular in some linker scripts.
This commit reveals board configurations that exclude some module but not all of its dependencies; for example, disabling CMD_NET but not CMD_NFS results in undefined symbols at link time.
Signed-off-by: Sebastien Carlier sebastien.carlier@gmail.com
git-bisect tells me that your patch (or whatever version of it was actually applied) causes this linker warning:
powerpc-linux-gnu-ld: Warning: lib_powerpc/fpu/libpostpowerpcfpu.o uses hard float, libpost.o uses soft float
See this thread for details: http://lists.denx.de/pipermail/u-boot/2011-January/085811.html
I have no idea how to fix this.
The issue is that the code under post/lib_powerpc/fpu/* is compiled with:
CFLAGS := $(shell echo $(CFLAGS) | sed s/-msoft-float//) CFLAGS += -mhard-float -fkeep-inline-functions
We need to see if we can avoid building the whole post/lib_powerpc/fpu/* dir if CONFIG_POST_FPU isn't set in CONFIG_POST.
- k
Dear Kumar Gala,
In message 356989C7-FA92-46D5-9FB6-5F9332ECBFD5@kernel.crashing.org you wrote:
The issue is that the code under post/lib_powerpc/fpu/* is compiled with:
CFLAGS := $(shell echo $(CFLAGS) | sed s/-msoft-float//) CFLAGS += -mhard-float -fkeep-inline-functions
We need to see if we can avoid building the whole post/lib_powerpc/fpu/* dir if CONFIG_POST_FPU isn't set in CONFIG_POST.
This might solve the warning in most cases - but what abut these where CONFIG_POST_FPU is defined? I mean, it is inherent that these tests need to execute FP instructions.
Best regards,
Wolfgang Denk
On Jan 25, 2011, at 12:36 AM, Wolfgang Denk wrote:
Dear Kumar Gala,
In message 356989C7-FA92-46D5-9FB6-5F9332ECBFD5@kernel.crashing.org you wrote:
The issue is that the code under post/lib_powerpc/fpu/* is compiled with:
CFLAGS := $(shell echo $(CFLAGS) | sed s/-msoft-float//) CFLAGS += -mhard-float -fkeep-inline-functions
We need to see if we can avoid building the whole post/lib_powerpc/fpu/* dir if CONFIG_POST_FPU isn't set in CONFIG_POST.
This might solve the warning in most cases - but what abut these where CONFIG_POST_FPU is defined? I mean, it is inherent that these tests need to execute FP instructions.
Best regards,
Wolfgang Denk
Actually we've dealt with this already:
commit ce82ff05388b5ddafdf6082ef0776cce72c40b1c Author: Yuri Tikhonov yur@emcraft.com Date: Sat Dec 20 14:54:21 2008 +0300
FPU POST: fix warnings when building with 2.18 binutils
When compile u-boot with the 2.18 binutils the following warning messages for each object file in post/lib_ppc/fpu/ is produced at the linking stage:
post/libpost.a(acc1.o) uses hard float, u-boot uses soft-float ...
...
However I think we just need to move the code a bit. Will post a patch
- k
- k
Kumar Gala wrote:
Actually we've dealt with this already:
commit ce82ff05388b5ddafdf6082ef0776cce72c40b1c Author: Yuri Tikhonov yur@emcraft.com Date: Sat Dec 20 14:54:21 2008 +0300
FPU POST: fix warnings when building with 2.18 binutils
Why don't we compile all of U-Boot with hard float by default? What's wrong with using floating point instructions in U-Boot?
On Jan 25, 2011, at 10:40 AM, Timur Tabi wrote:
Kumar Gala wrote:
Actually we've dealt with this already:
commit ce82ff05388b5ddafdf6082ef0776cce72c40b1c Author: Yuri Tikhonov yur@emcraft.com Date: Sat Dec 20 14:54:21 2008 +0300
FPU POST: fix warnings when building with 2.18 binutils
Why don't we compile all of U-Boot with hard float by default? What's wrong with using floating point instructions in U-Boot?
* still have to deal with cores that dont have FP
- k
Kumar Gala wrote:
- still have to deal with cores that dont have FP
But when will gcc generate FP instructions? If we compile with soft-float, will it link in an FP library and use it?
My point is that compiling with soft-float doesn't make much more sense than compiling with hard-float, since there won't be any floating point instructions in either case.
Dear Timur Tabi,
In message 4D3F16C7.7040000@freescale.com you wrote:
But when will gcc generate FP instructions? If we compile with soft-float, will it link in an FP library and use it?
GCC will (in addition to the obvious case of operations of FP data types) generate FP instructions for a number of "small data copy" operations, like assignment of structs etc.
My point is that compiling with soft-float doesn't make much more sense than compiling with hard-float, since there won't be any floating point instructions in either case.
You are wrong.
Best regards,
Wolfgang Denk
On Tue, 25 Jan 2011 11:49:53 -0600 Kumar Gala galak@kernel.crashing.org wrote:
On Jan 25, 2011, at 10:40 AM, Timur Tabi wrote:
Kumar Gala wrote:
Actually we've dealt with this already:
commit ce82ff05388b5ddafdf6082ef0776cce72c40b1c Author: Yuri Tikhonov yur@emcraft.com Date: Sat Dec 20 14:54:21 2008 +0300
FPU POST: fix warnings when building with 2.18 binutils
Why don't we compile all of U-Boot with hard float by default? What's wrong with using floating point instructions in U-Boot?
- still have to deal with cores that dont have FP
On cores that have FP (at least those that support the FPU POST, and which are currently having problems), use hard float, enable MSR[FP] or equivalent, and let GCC use FP for various tasks if it wants. This shouldn't involve much more complexity than adding a small amount of init, which you'd need for the POST anyway.
On cores that don't have FP, use soft float, and don't include the FPU POST code. This should not be any different than today, except for adding another compiler flag that depends on the build target.
-Scott
Dear Scott Wood,
In message 20110125140547.2825fdad@udp111988uds.am.freescale.net you wrote:
On cores that have FP (at least those that support the FPU POST, and which are currently having problems), use hard float, enable MSR[FP] or equivalent, and let GCC use FP for various tasks if it wants. This shouldn't involve much more complexity than adding a small amount of init, which you'd need for the POST anyway.
On cores that don't have FP, use soft float, and don't include the FPU POST code. This should not be any different than today, except for adding another compiler flag that depends on the build target.
And why exactly should we do all this, given the fact that there are no intentions to work with floating point data in U-Boot?
Best regards,
Wolfgang Denk
On Tue, 25 Jan 2011 21:19:19 +0100 Wolfgang Denk wd@denx.de wrote:
Dear Scott Wood,
In message 20110125140547.2825fdad@udp111988uds.am.freescale.net you wrote:
On cores that have FP (at least those that support the FPU POST, and which are currently having problems), use hard float, enable MSR[FP] or equivalent, and let GCC use FP for various tasks if it wants. This shouldn't involve much more complexity than adding a small amount of init, which you'd need for the POST anyway.
On cores that don't have FP, use soft float, and don't include the FPU POST code. This should not be any different than today, except for adding another compiler flag that depends on the build target.
And why exactly should we do all this,
To fix the FPU POST build errors.
Do you have a simpler way to do this? Note that for any board that doesn't currently have a problem, "all this" means no change at all.
And for those that do have a problem, the change is pretty minor.
given the fact that there are no intentions to work with floating point data in U-Boot?
FPU POST doesn't count?
Or are you saying FPU POST should be removed?
-Scott
Dear Scott Wood,
In message 20110125143740.2e1f2c84@udp111988uds.am.freescale.net you wrote:
Do you have a simpler way to do this? Note that for any board that
e009cde powerpc: Fix FPU post related link warnings
?
given the fact that there are no intentions to work with floating point data in U-Boot?
FPU POST doesn't count?
No, it does not count, because it is a very special situation where we are executing instructions that are guaranteed to be never used in any real code in U-Boot.
Or are you saying FPU POST should be removed?
Of course not.
Best regards,
Wolfgang Denk
On Jan 25, 2011, at 3:13 PM, Wolfgang Denk wrote:
Dear Scott Wood,
In message 20110125143740.2e1f2c84@udp111988uds.am.freescale.net you wrote:
Do you have a simpler way to do this? Note that for any board that
e009cde powerpc: Fix FPU post related link warnings
?
given the fact that there are no intentions to work with floating point data in U-Boot?
FPU POST doesn't count?
No, it does not count, because it is a very special situation where we are executing instructions that are guaranteed to be never used in any real code in U-Boot.
Or are you saying FPU POST should be removed?
Of course not.
I thank you all, as I've enjoyed this thread for something we've just fixed :)
- k
- k
On Tue, 25 Jan 2011 23:22:34 -0600 Kumar Gala galak@kernel.crashing.org wrote:
On Jan 25, 2011, at 3:13 PM, Wolfgang Denk wrote:
Dear Scott Wood,
In message 20110125143740.2e1f2c84@udp111988uds.am.freescale.net you wrote:
Do you have a simpler way to do this? Note that for any board that
e009cde powerpc: Fix FPU post related link warnings
?
given the fact that there are no intentions to work with floating point data in U-Boot?
FPU POST doesn't count?
No, it does not count, because it is a very special situation where we are executing instructions that are guaranteed to be never used in any real code in U-Boot.
Or are you saying FPU POST should be removed?
Of course not.
I thank you all, as I've enjoyed this thread for something we've just fixed :)
The joys of e-mail threading. :-)
-Scott
Dear Timur Tabi,
In message 4D3EFCF2.4060706@freescale.com you wrote:
Why don't we compile all of U-Boot with hard float by default? What's wrong with using floating point instructions in U-Boot?
We don't need it.
Why doesn't the Linux kernel use floating point instructions?
Best regards,
Wolfgang Denk
Wolfgang Denk wrote:
Why doesn't the Linux kernel use floating point instructions?
Because dealing with FP in a multi-tasking OS is messy. U-Boot doesn't have that problem.
Dear Timur Tabi,
In message 4D3F1674.10509@freescale.com you wrote:
Because dealing with FP in a multi-tasking OS is messy. U-Boot doesn't have that problem.
But we also do not have any need for FP operations either. It would just add to the complexity (and to the memory foot print, especially on systems without FPU where we would have to provide soft-float libraries, plus eventually variantes for SPEv1 and SPEvv2 and whatever - not to mention that tghis will be needed for all the non-PPC architectures as well).
Best regards,
Wolfgang Denk
Wolfgang Denk wrote:
But we also do not have any need for FP operations either. It would just add to the complexity (and to the memory foot print, especially on systems without FPU where we would have to provide soft-float libraries, plus eventually variantes for SPEv1 and SPEvv2 and whatever - not to mention that tghis will be needed for all the non-PPC architectures as well).
I think you misunderstand. I'm not saying that we should use FP instructions in U-Boot. I'm saying that since we *don't* use FP instructions in U-Boot, we can just turn on hard-float and avoid any incompatibility with CONFIG_POST_FPU, because all of U-Boot will then be compiled with hard-float.
Dear Timur Tabi,
In message 4D3F1D25.4070807@freescale.com you wrote:
I think you misunderstand. I'm not saying that we should use FP instructions in U-Boot. I'm saying that since we *don't* use FP instructions in U-Boot, we can just turn on hard-float and avoid any incompatibility with CONFIG_POST_FPU, because all of U-Boot will then be compiled with hard-float.
If we let him, GCC would generate FP instructions in a number of places where you don't expect them, even whithout any FP variables or explicit FP operations in the whole code C or assembler input.
Best regards,
Wolfgang Denk
participants (13)
-
Albert ARIBAUD -
Andre Schwarz -
Andreas Bießmann -
Detlev Zundel -
Graeme Russ -
Kumar Gala -
Mike Frysinger -
Reinhard Meyer -
Scott Wood -
Sebastien Carlier -
Stefano Babic -
Timur Tabi -
Wolfgang Denk