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).

Quoted 2 lines · Sebastien Carlier

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 :)

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".

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<[email protected]>

---
  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 at lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Date: Tue, 09 Nov 2010 10:15:31 +0100
From: Andre Schwarz <[email protected]>
To: Sebastien Carlier <[email protected]>
CC: u-boot at lists.denx.de, Timur Tabi <[email protected]>,
Kim Phillips <[email protected]>
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.

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.

NOTE: This does not include the actual patch as it is too large for the mailing list (418 kB).

Signed-off-by Sebastien Carlier <[email protected]>

NOTE: This does not include the actual patch as it is too large for the mailing list (418 kB).

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.

 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 +-

the config.mk looks weird:

(quoted diff) +3 -0

+cmd_link_o_target = $(if $(strip $1),\
+                      $(LD) -r -o $@ $1 ,\
+                      rm -f $@; $(AR) rcs $@ )

why do you need the rm/ar ?

Quoted 6 lines · 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:

(quoted diff) +3 -0

+cmd_link_o_target = $(if $(strip $1),\
+                      $(LD) -r -o $@ $1 ,\
+                      rm -f $@; $(AR) rcs $@ )

why do you need the rm/ar ?

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:'

Quoted 5 lines · Mike Frysinger

the config.mk looks weird:

(quoted diff) +3 -0

+cmd_link_o_target = $(if $(strip $1),\
+                      $(LD) -r -o $@ $1 ,\
+                      rm -f $@; $(AR) rcs $@ )

Quoted 1 line

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).

Quoted 8 lines · On Wednesday, November 10, 2010 03:07:08 Sebastien Carlier wrote:

Quoted 6 lines · Mike Frysinger

the config.mk looks weird:

(quoted diff) +3 -0

+cmd_link_o_target = $(if $(strip $1),\
+                      $(LD) -r -o $@ $1 ,\
+                      rm -f $@; $(AR) rcs $@ )

why do you need the rm/ar ?

Quoted 4 lines

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 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.

Good suggestion, done in v3:

Quoted 1 line · In message <[email protected]> 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.

Quoted 10 lines · Sebastien Carlier

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 Bytes

For other boards it's only a few hundred bytes, but why do we see such big increase here?

Quoted 3 lines · On Monday, November 15, 2010 05:54:07 Wolfgang Denk wrote:

Quoted 2 lines · Sebastien Carlier

I just uploaded the revised patch here:

	http://www.denx.de/wiki/pub/U-Boot/TooBigPatches/0001-Switch-from-

Quoted 23 lines

Quoted 8 lines

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

Quoted 6 lines

-------------------------------

		Delta:   +3896 Bytes

For 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 ...

replace the '$7 == "3"' check with whatever section number you want to check. in my case, 3 is ".text".

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:

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?

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?

Quoted 16 lines · Wolfgang Denk

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

Quoted 2 lines

For 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.

Quoted 20 lines · Wolfgang Denk

Quoted 18 lines

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?

Quoted 5 lines

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.

Quoted 24 lines · On Monday, November 15, 2010 07:13:03 Sebastien Carlier wrote:

Quoted 23 lines · Wolfgang Denk

Quoted 12 lines

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

Quoted 6 lines

-------------------------------

		Delta:   +3896 Bytes

For 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:

Quoted 5 lines

Quoted 2 lines

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].

Quoted 27 lines

Quoted 27 lines · On Monday, November 15, 2010 07:13:03 Sebastien Carlier wrote:

Quoted 25 lines · Wolfgang Denk

Quoted 12 lines

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

Quoted 6 lines

-------------------------------

		Delta:   +3896 Bytes

For 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.

Quoted 5 lines

Quoted 2 lines

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 ...

I notice that the patch affects the size of the resulting U-Boot images.

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?

Quoted 2 lines · Wolfgang Denk

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 at lists.denx.de/msg41762.html
    http://www.mail-archive.com/u-boot at 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...

Quoted 11 lines · On Wednesday, November 17, 2010 08:30:56 Sebastien Carlier wrote:

Quoted 2 lines · Wolfgang Denk

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 at lists.denx.de/msg41762.html
    http://www.mail-archive.com/u-boot at lists.denx.de/msg42063.html

Quoted 2 lines

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.

Quoted 11 lines · Mike Frysinger

Quoted 9 lines · 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 at lists.denx.de/msg41762.html
    http://www.mail-archive.com/u-boot at 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...

Quoted 3 lines

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.

Quoted 9 lines

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'
...

Quoted 1 line

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?

Dear Sebastien Carlier,

Quoted 9 lines · In message<[email protected]> you wrote:

Quoted 9 lines

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'
...

Quoted 6 lines

Quoted 1 line

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

Quoted 12 lines

  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:

Dear Albert ARIBAUD,

Quoted 12 lines · In message<[email protected]> you wrote:

Quoted 12 lines

   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)

....

Quoted 4 lines

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

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.

Quoted 4 lines · Albert ARIBAUD

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.

(quoted diff) +0 -1

-mike

common/Makefile +0 -1

index e0db382..d38aa7b 100644
@@ -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

Dear Mike Frysinger,

Quoted 2 lines · In message<[email protected]> you wrote:

sizes can be a bit large. if everyone was using -ffunction-sections/-fdata- sections

? Could you please complete that sentence?

Quoted 5 lines · Mike Frysinger

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.

Quoted 2 lines

sizes can be a bit large. if everyone was using
-ffunction-sections/-fdata- sections

? Could you please complete that sentence?

Quoted 23 lines

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.

common/Makefile +4 -4

index e0db382..d38aa7b 100644
@@ -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
 

Quoted 3 lines

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 ?

Le 18/11/2010 23:33, Wolfgang Denk a ?crit :

Quoted 7 lines

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.

Quoted 5 lines

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:

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?

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?

Quoted 3 lines · In message <sebastien.carlier@1e724f1c01c015f817d5e33b57e7134d4468dbcc> you…

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.

Quoted 2 lines

(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.

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...

Dear Sebastien Carlier,

Quoted 6 lines · In message<sebastien.carlier@f67ce90ecc8846695b88fb9ac74f99d56979b90a> you…

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

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.

Dear Albert ARIBAUD,

Quoted 4 lines · In message<[email protected]> 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.

Quoted 6 lines

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

Quoted 1 line · In message <sebastien.carlier@f67ce90ecc8846695b88fb9ac74f99d56979b90a> you…

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, ...

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.

Dear Wolfgang,

Quoted 16 lines · Wolfgang Denk

Quoted 1 line · In message<sebastien.carlier@f67ce90ecc8846695b88fb9ac74f99d56979b90a> you…

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

Quoted 1 line

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!

Quoted 3 lines

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 :

Quoted 5 lines

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.

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.

Quoted 8 lines

Le 19/11/2010 13:33, Sebastien Carlier a ?crit :

Quoted 4 lines

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.

Quoted 4 lines

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.

Dear Albert,

Quoted 15 lines · Albert ARIBAUD

Quoted 8 lines

Le 19/11/2010 13:33, Sebastien Carlier a ?crit :

Quoted 4 lines

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.

Quoted 8 lines

Quoted 4 lines

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?

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
}

*maybe* one can define several areas for CODE in the MEMORY section?

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.

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?

Quoted 6 lines · Wolfgang Denk

Quoted 1 line · In message <[email protected]> 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?

Quoted 1 line

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-

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.

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.

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 <[email protected]>

Quoted 11 lines · 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".

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.

Quoted 7 lines

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 <[email protected]>

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.

Dear Kumar Gala,

Quoted 7 lines · In message <[email protected]> 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 <[email protected]>
Date:   Sat Dec 20 14:54:21 2008 +0300

FPU POST: fix warnings when building with 2.18 binutils

Quoted 7 lines · Kumar Gala

Actually we've dealt with this already:

commit ce82ff05388b5ddafdf6082ef0776cce72c40b1c

Author: Yuri Tikhonov <[email protected]>
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

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.

Quoted 7 lines · Timur Tabi

Quoted 6 lines · Kumar Gala

Actually we've dealt with this already:

commit ce82ff05388b5ddafdf6082ef0776cce72c40b1c

Author: Yuri Tikhonov <[email protected]>
Date:   Sat Dec 20 14:54:21 2008 +0300

Quoted 4 lines

Quoted 1 line

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.

Dear Scott Wood,

Quoted 7 lines · In message <[email protected]> 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.

Quoted 3 lines

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?

Do you have a simpler way to do this? Note that for any board that

Quoted 2 lines

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?

Dear Scott Wood,

Quoted 2 lines · In message <[email protected]> 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

?

Quoted 4 lines

Quoted 2 lines

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.

Quoted 1 line

Or are you saying FPU POST should be removed?

Of course not.

Quoted 19 lines · Wolfgang Denk

Dear Scott Wood,

Quoted 2 lines · In message <[email protected]> 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

?

Quoted 4 lines

Quoted 2 lines

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.

Quoted 3 lines

Quoted 1 line

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 :)

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?

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.

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.