Skip to contentSkip to conversation

Fix linker scripts: add NOLOAD atribute to .bss/.sbss sections

PATCH New Wolfgang Denk 8 participants 22 messages Dec 7, 2007 – Feb 15, 2008

lore
Share & tools
lore
#0 lore raw

PATCH 1/1 Fix linker scripts: add NOLOAD atribute to .bss/.sbss sections

With recent toolchain versions, some boards would not build because
or errors like this one (here for ocotea board when building with
ELDK 4.2):
ppc_4xx-ld: section .bootpg [fffff000 -> fffff23b] overlaps section .bss [fffee900 -> fffff8ab]

For many boards, the .bss section is big enough that it wraps around at the end of the address space (0xFFFFFFFF), so the problem will not be visible unless you use a 64 bit tool chain for development. On some boards however, changes to the code size (due to different optimizations) we bail out with section overlaps like above.

The fix is to add the NOLOAD attribute to the .bss and .sbss sections, telling the linker that .bss does not consume any space in the image.

---
 board/BuS/EB+MCF-EV123/u-boot.lds      |    2 +-
 board/LEOX/elpt860/u-boot.lds          |    2 +-
 board/MAI/AmigaOneG3SE/u-boot.lds      |    2 +-
 board/Marvell/db64360/u-boot.lds       |    2 +-
 board/Marvell/db64460/u-boot.lds       |    2 +-
 board/RPXClassic/u-boot.lds            |    2 +-
 board/RPXlite/u-boot.lds               |    2 +-
 board/RPXlite_dw/u-boot.lds            |    2 +-
 board/RRvision/u-boot.lds              |    2 +-
 board/adder/u-boot.lds                 |    2 +-
 board/ads5121/u-boot.lds               |    2 +-
 board/adsvix/u-boot.lds                |    2 +-
 board/altera/dk1c20/u-boot.lds         |    2 +-
 board/altera/dk1s10/u-boot.lds         |    2 +-
 board/altera/ep1c20/u-boot.lds         |    4 ++--
 board/altera/ep1s10/u-boot.lds         |    4 ++--
 board/altera/ep1s40/u-boot.lds         |    4 ++--
 board/amcc/acadia/u-boot-nand.lds      |    2 +-
 board/amcc/acadia/u-boot.lds           |    2 +-
 board/amcc/bamboo/u-boot-nand.lds      |    2 +-
 board/amcc/bamboo/u-boot.lds           |    2 +-
 board/amcc/bubinga/u-boot.lds          |    2 +-
 board/amcc/ebony/u-boot.lds            |    2 +-
 board/amcc/katmai/u-boot.lds           |    2 +-
 board/amcc/luan/u-boot.lds             |    2 +-
 board/amcc/ocotea/u-boot.lds           |    2 +-
 board/amcc/sequoia/u-boot-nand.lds     |    2 +-
 board/amcc/sequoia/u-boot.lds          |    2 +-
 board/amcc/taihu/u-boot.lds            |    2 +-
 board/amcc/taishan/u-boot.lds          |    2 +-
 board/amcc/walnut/u-boot.lds           |    2 +-
 board/amcc/yosemite/u-boot.lds         |    2 +-
 board/amcc/yucca/u-boot.lds            |    2 +-
 board/amirix/ap1000/u-boot.lds         |    2 +-
 board/armadillo/u-boot.lds             |    2 +-
 board/assabet/u-boot.lds               |    2 +-
 board/at91rm9200dk/u-boot.lds          |    2 +-
 board/atmel/atstk1000/u-boot.lds       |    2 +-
 board/c2mon/u-boot.lds                 |    2 +-
 board/cds/mpc8541cds/u-boot.lds        |    2 +-
 board/cds/mpc8548cds/u-boot.lds        |    2 +-
 board/cds/mpc8555cds/u-boot.lds        |    2 +-
 board/cerf250/u-boot.lds               |    2 +-
 board/cm4008/u-boot.lds                |    2 +-
 board/cm41xx/u-boot.lds                |    2 +-
 board/cm5200/u-boot.lds                |    2 +-
 board/cmc_pu2/u-boot.lds               |    2 +-
 board/cobra5272/u-boot.lds             |    2 +-
 board/cogent/u-boot.lds                |    2 +-
 board/cradle/u-boot.lds                |    2 +-
 board/cray/L1/u-boot.lds               |    2 +-
 board/csb226/u-boot.lds                |    2 +-
 board/csb272/u-boot.lds                |    2 +-
 board/csb472/u-boot.lds                |    2 +-
 board/csb637/u-boot.lds                |    2 +-
 board/dave/B2/u-boot.lds               |    2 +-
 board/dave/PPChameleonEVB/u-boot.lds   |    2 +-
 board/davinci/dv-evm/u-boot.lds        |    2 +-
 board/davinci/schmoogie/u-boot.lds     |    2 +-
 board/davinci/sonata/u-boot.lds        |    2 +-
 board/dbau1x00/u-boot.lds              |    4 ++--
 board/delta/u-boot.lds                 |    2 +-
 board/dnp1110/u-boot.lds               |    2 +-
 board/eltec/bab7xx/u-boot.lds          |    2 +-
 board/eltec/elppc/u-boot.lds           |    2 +-
 board/eltec/mhpc/u-boot.lds            |    2 +-
 board/emk/top860/u-boot.lds            |    2 +-
 board/ep7312/u-boot.lds                |    2 +-
 board/ep88x/u-boot.lds                 |    2 +-
 board/eric/u-boot.lds                  |    2 +-
 board/esd/adciop/u-boot.lds            |    2 +-
 board/esd/apc405/u-boot.lds            |    2 +-
 board/esd/ar405/u-boot.lds             |    2 +-
 board/esd/ash405/u-boot.lds            |    2 +-
 board/esd/canbt/u-boot.lds             |    2 +-
 board/esd/cms700/u-boot.lds            |    2 +-
 board/esd/cpci2dp/u-boot.lds           |    2 +-
 board/esd/cpci405/u-boot.lds           |    2 +-
 board/esd/cpci440/u-boot.lds           |    2 +-
 board/esd/cpci750/u-boot.lds           |    2 +-
 board/esd/cpciiser4/u-boot.lds         |    2 +-
 board/esd/dasa_sim/u-boot.lds          |    2 +-
 board/esd/dp405/u-boot.lds             |    2 +-
 board/esd/du405/u-boot.lds             |    2 +-
 board/esd/hh405/u-boot.lds             |    2 +-
 board/esd/hub405/u-boot.lds            |    2 +-
 board/esd/ocrtc/u-boot.lds             |    2 +-
 board/esd/pci405/u-boot.lds            |    2 +-
 board/esd/plu405/u-boot.lds            |    2 +-
 board/esd/pmc405/u-boot.lds            |    2 +-
 board/esd/tasreg/u-boot.lds            |    2 +-
 board/esd/voh405/u-boot.lds            |    2 +-
 board/esd/vom405/u-boot.lds            |    2 +-
 board/esd/wuh405/u-boot.lds            |    2 +-
 board/esteem192e/u-boot.lds            |    2 +-
 board/etx094/u-boot.lds                |    2 +-
 board/evb4510/u-boot.lds               |    2 +-
 board/evb64260/u-boot.lds              |    2 +-
 board/exbitgen/u-boot.lds              |    2 +-
 board/fads/u-boot.lds                  |    2 +-
 board/flagadm/u-boot.lds               |    2 +-
 board/freescale/m5235evb/u-boot.lds    |    2 +-
 board/freescale/m5249evb/u-boot.lds    |    2 +-
 board/freescale/m5253evbe/u-boot.lds   |    2 +-
 board/freescale/m5329evb/u-boot.lds    |    2 +-
 board/freescale/m54455evb/u-boot.lds   |    2 +-
 board/freescale/mpc8544ds/u-boot.lds   |    2 +-
 board/freescale/mpc8641hpcn/u-boot.lds |    2 +-
 board/g2000/u-boot.lds                 |    2 +-
 board/gcplus/u-boot.lds                |    2 +-
 board/gen860t/u-boot-flashenv.lds      |    2 +-
 board/gen860t/u-boot.lds               |    2 +-
 board/genietv/u-boot.lds               |    2 +-
 board/gth/u-boot.lds                   |    2 +-
 board/gth2/u-boot.lds                  |    4 ++--
 board/hermes/u-boot.lds                |    2 +-
 board/hymod/u-boot.lds                 |    2 +-
 board/icu862/u-boot.lds                |    2 +-
 board/idmr/u-boot.lds                  |    2 +-
 board/impa7/u-boot.lds                 |    2 +-
 board/incaip/u-boot.lds                |    4 ++--
 board/innokom/u-boot.lds               |    2 +-
 board/ip860/u-boot.lds                 |    2 +-
 board/ivm/u-boot.lds                   |    2 +-
 board/ixdp425/u-boot.lds               |    2 +-
 board/jse/u-boot.lds                   |    2 +-
 board/kb9202/u-boot.lds                |    2 +-
 board/kup/kup4k/u-boot.lds             |    2 +-
 board/kup/kup4x/u-boot.lds             |    2 +-
 board/lantec/u-boot.lds                |    2 +-
 board/lart/u-boot.lds                  |    2 +-
 board/logodl/u-boot.lds                |    2 +-
 board/lpc2292sodimm/u-boot.lds         |    2 +-
 board/lpd7a40x/u-boot.lds              |    2 +-
 board/lubbock/u-boot.lds               |    2 +-
 board/lwmon/u-boot.lds                 |    2 +-
 board/lwmon5/u-boot.lds                |    2 +-
 board/m5271evb/u-boot.lds              |    2 +-
 board/m5272c3/u-boot.lds               |    2 +-
 board/m5282evb/u-boot.lds              |    2 +-
 board/mbx8xx/u-boot.lds                |    2 +-
 board/ml2/u-boot.lds                   |    2 +-
 board/modnet50/u-boot.lds              |    2 +-
 board/mousse/u-boot.lds                |    2 +-
 board/mp2usb/u-boot.lds                |    2 +-
 board/mpc7448hpc2/u-boot.lds           |    2 +-
 board/mpc8540ads/u-boot.lds            |    2 +-
 board/mpc8540eval/u-boot.lds           |    2 +-
 board/mpc8560ads/u-boot.lds            |    2 +-
 board/mpc8568mds/u-boot.lds            |    2 +-
 board/mpl/mip405/u-boot.lds            |    2 +-
 board/mpl/pip405/u-boot.lds            |    2 +-
 board/mpl/vcma9/u-boot.lds             |    2 +-
 board/mvs1/u-boot.lds                  |    2 +-
 board/mx1ads/u-boot.lds                |    2 +-
 board/mx1fs2/u-boot.lds                |    2 +-
 board/nc650/u-boot.lds                 |    2 +-
 board/netphone/u-boot.lds              |    2 +-
 board/netstal/hcu4/u-boot.lds          |    2 +-
 board/netstal/hcu5/u-boot.lds          |    2 +-
 board/netstar/u-boot.lds               |    2 +-
 board/netta/u-boot.lds                 |    2 +-
 board/netta2/u-boot.lds                |    2 +-
 board/netvia/u-boot.lds                |    2 +-
 board/ns9750dev/u-boot.lds             |    2 +-
 board/nx823/u-boot.lds                 |    2 +-
 board/omap1510inn/u-boot.lds           |    2 +-
 board/omap1610inn/u-boot.lds           |    2 +-
 board/omap2420h4/u-boot.lds            |    2 +-
 board/omap5912osk/u-boot.lds           |    2 +-
 board/omap730p2/u-boot.lds             |    2 +-
 board/pb1x00/u-boot.lds                |    4 ++--
 board/pcippc2/u-boot.lds               |    2 +-
 board/pcs440ep/u-boot.lds              |    2 +-
 board/pleb2/u-boot.lds                 |    2 +-
 board/pm854/u-boot.lds                 |    2 +-
 board/pm856/u-boot.lds                 |    2 +-
 board/ppmc7xx/u-boot.lds               |    2 +-
 board/prodrive/alpr/u-boot.lds         |    2 +-
 board/prodrive/p3mx/u-boot.lds         |    2 +-
 board/prodrive/p3p440/u-boot.lds       |    2 +-
 board/prodrive/pdnb3/u-boot.lds        |    2 +-
 board/psyent/pci5441/u-boot.lds        |    4 ++--
 board/psyent/pk1c20/u-boot.lds         |    4 ++--
 board/purple/u-boot.lds                |    4 ++--
 board/pxa255_idp/u-boot.lds            |    2 +-
 board/quantum/u-boot.lds               |    2 +-
 board/r360mpi/u-boot.lds               |    2 +-
 board/r5200/u-boot.lds                 |    2 +-
 board/rbc823/u-boot.lds                |    2 +-
 board/rmu/u-boot.lds                   |    2 +-
 board/rsdproto/u-boot.lds              |    2 +-
 board/sandburst/karef/u-boot.lds       |    2 +-
 board/sandburst/metrobox/u-boot.lds    |    2 +-
 board/sbc2410x/u-boot.lds              |    2 +-
 board/sbc405/u-boot.lds                |    2 +-
 board/sbc8560/u-boot.lds               |    2 +-
 board/sbc8641d/u-boot.lds              |    2 +-
 board/sc3/u-boot.lds                   |    2 +-
 board/sc520_cdp/u-boot.lds             |    2 +-
 board/sc520_spunk/u-boot.lds           |    2 +-
 board/scb9328/u-boot.lds               |    2 +-
 board/shannon/u-boot.lds               |    2 +-
 board/siemens/CCM/u-boot.lds           |    2 +-
 board/siemens/IAD210/u-boot.lds        |    2 +-
 board/siemens/SMN42/u-boot.lds         |    2 +-
 board/siemens/pcu_e/u-boot.lds         |    2 +-
 board/sixnet/u-boot.lds                |    2 +-
 board/smdk2400/u-boot.lds              |    2 +-
 board/smdk2410/u-boot.lds              |    2 +-
 board/snmc/qs850/u-boot.lds            |    2 +-
 board/snmc/qs860t/u-boot.lds           |    2 +-
 board/spc1920/u-boot.lds               |    2 +-
 board/spd8xx/u-boot.lds                |    2 +-
 board/ssv/adnpesc1/u-boot.lds          |    2 +-
 board/stxgp3/u-boot.lds                |    2 +-
 board/stxssa/u-boot.lds                |    2 +-
 board/stxxtc/u-boot.lds                |    2 +-
 board/svm_sc8xx/u-boot.lds             |    2 +-
 board/sx1/u-boot.lds                   |    2 +-
 board/tb0229/u-boot.lds                |    4 ++--
 board/tqm85xx/u-boot.lds               |    2 +-
 board/tqm8xx/u-boot.lds                |    2 +-
 board/trab/u-boot.lds                  |    2 +-
 board/trizepsiv/u-boot.lds             |    2 +-
 board/uc100/u-boot.lds                 |    2 +-
 board/v37/u-boot.lds                   |    2 +-
 board/versatile/u-boot.lds             |    2 +-
 board/voiceblue/u-boot.lds             |    2 +-
 board/w7o/u-boot.lds                   |    2 +-
 board/wepep250/u-boot.lds              |    2 +-
 board/westel/amx860/u-boot.lds         |    2 +-
 board/xaeniax/u-boot.lds               |    2 +-
 board/xilinx/ml300/u-boot.lds          |    2 +-
 board/xm250/u-boot.lds                 |    2 +-
 board/xpedite1k/u-boot.lds             |    2 +-
 board/xsengine/u-boot.lds              |    2 +-
 board/zeus/u-boot.lds                  |    2 +-
 board/zylonite/u-boot.lds              |    2 +-
 cpu/mpc5xx/u-boot.lds                  |    2 +-
 cpu/mpc5xxx/u-boot-customlayout.lds    |    2 +-
 cpu/mpc5xxx/u-boot.lds                 |    2 +-
 cpu/mpc8220/u-boot.lds                 |    2 +-
 cpu/mpc824x/u-boot.lds                 |    2 +-
 cpu/mpc8260/u-boot.lds                 |    2 +-
 cpu/mpc83xx/u-boot.lds                 |    2 +-
 nand_spl/board/amcc/acadia/u-boot.lds  |    2 +-
 nand_spl/board/amcc/bamboo/u-boot.lds  |    2 +-
 nand_spl/board/amcc/sequoia/u-boot.lds |    2 +-
 249 files changed, 260 insertions(+), 260 deletions(-)

Patch exceeds mailing list's message size limit.

Please see ftp://ftp.denx.de/pub/tmp/Fix-linker-scripts-BSS-NOLOAD.patch

#1 lore raw

PATCH 1/1 Fix linker scripts: add NOLOAD atribute to .bss/.sbss sections

Quoted 11 lines · On Fri, 7 Dec 2007 12:16:54 +0100 Wolfgang Denk <[email protected]> wrote:

With recent toolchain versions, some boards would not build because
or errors like this one (here for ocotea board when building with
ELDK 4.2):
ppc_4xx-ld: section .bootpg [fffff000 -> fffff23b] overlaps section .bss [fffee900 -> fffff8ab]

For many boards, the .bss section is big enough that it wraps around at the end of the address space (0xFFFFFFFF), so the problem will not be visible unless you use a 64 bit tool chain for development. On some boards however, changes to the code size (due to different optimizations) we bail out with section overlaps like above.

Quoted 3 lines

The fix is to add the NOLOAD attribute to the .bss and .sbss sections, telling the linker that .bss does not consume any space in the image.

YAY! I've been having to work around this for a while now. Looking forward to trying it out.

josh

#2 lore raw

PATCH 1/1 Fix linker scripts: add NOLOAD atribute to .bss/.sbss sections

Hi All,

This fix doesn't work with binutils-2.18. I'm building u-boot for the amcc yosemite board using cygwin and cross binutils-2.18/gcc-4.2.2 for a powerpc-eabi target. The linker complains that "section .text can't be allocated in segment 0." The .bss section is by default a NOLOAD section with binutils-2.18 meaning it occupies no space in the file. However, the .bss section is an ALLOC section meaning it does occupy space in target memory. The linker runs an error check to make sure all sections will fit within the file and all sections will fit within target memory. All sections
do fit within the file, however the sections do not fit within target memory because of the wrap around end of memory.

We could definitely drop the TEXT_BASE address lower which would fix the problem, but isn't ideal since the image would take up more flash for no reason. We could link with TEXT_BASE=0 and then burn it to flash at address 0xFFF80000 (this is where the current TEXT_BASE is for the yosemite board). Whats the reason it's linked at 0xFFF80000 anyway? Is there an elf loader which burns it into flash? There's also the 'AT' attribute in the linker script which may help, however, I don't quite understand the use of it yet. Any suggestions on how to approach this?

Thanks,
Brian

Quoted 37 lines · Josh Boyer-3 wrote:
Quoted 12 lines · On Fri, 7 Dec 2007 12:16:54 +0100 Wolfgang Denk <[email protected]> wrote:

With recent toolchain versions, some boards would not build because or errors like this one (here for ocotea board when building with ELDK 4.2):
ppc_4xx-ld: section .bootpg [fffff000 -> fffff23b] overlaps section .bss [fffee900 -> fffff8ab]

For many boards, the .bss section is big enough that it wraps around at the end of the address space (0xFFFFFFFF), so the problem will not be visible unless you use a 64 bit tool chain for development. On some boards however, changes to the code size (due to different optimizations) we bail out with section overlaps like above.

Quoted 3 lines

The fix is to add the NOLOAD attribute to the .bss and .sbss sections, telling the linker that .bss does not consume any space in the image.

YAY! I've been having to work around this for a while now. Looking forward to trying it out.

josh

-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
U-Boot-Users mailing list
U-Boot-Users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Signature · 2 lines
View this message in context: http://www.nabble.com/-PATCH--Fix-linker-scripts%3A-add-NOLOAD-atribute-to-.bss-.sbss-sections-tp14210775p14285357.html
Sent from the Uboot - Users mailing list archive at Nabble.com.
#3 lore raw

PATCH 1/1 Fix linker scripts: add NOLOAD atribute to .bss/.sbss sections

Quoted 5 lines · brino

Hi All,

This fix doesn't work with binutils-2.18. I'm building u-boot for the amcc yosemite board using cygwin and cross binutils-2.18/gcc-4.2.2 for a powerpc-eabi target.

Yes, binutils-2.18 have this broken. binutils-2.17 work fine.

Quoted 10 lines

The linker complains that "section .text can't be
allocated in segment 0." The .bss section is by default a NOLOAD section with binutils-2.18 meaning it occupies no space in the file. However, the .bss section is an ALLOC section meaning it does occupy space in target memory. The linker runs an error check to make sure all sections will fit within the file and all sections will fit within target memory. All sections
do fit within the file, however the sections do not fit within target memory because of the wrap around end of memory.

Quoted 8 lines

We could definitely drop the TEXT_BASE address lower which would fix the problem, but isn't ideal since the image would take up more flash for no reason. We could link with TEXT_BASE=0 and then burn it to flash at address 0xFFF80000 (this is where the current TEXT_BASE is for the yosemite board). Whats the reason it's linked at 0xFFF80000 anyway? Is there an elf loader which burns it into flash? There's also the 'AT' attribute in the linker script which may help, however, I don't quite understand the use of it yet. Any suggestions on how to approach this?

I am about to verify the latest binutils-snapshot. There have been the following patch included:
http://sourceware.org/ml/binutils/2007-11/msg00235.html
which should fix that issue.

Please be patient... I'll give you an update ASAP.

Regards,

Clemens Koller
__________________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Stra?e 45/1
Linhof Werksgel?nde
D-81379 M?nchen
Tel.089-741518-50
Fax 089-741518-19
http://www.anagramm-technology.com

#4 lore raw

[U-Boot-Users] fixed: Re: [PATCH] Fix linker scripts: add NOLOAD atribute to .bss/.sbss sections

[CCed to current thread at binutils list: Re: binutils-2.18 and U-Boot]

Quoted 8 lines · Clemens Koller
Quoted 5 lines · brino

Hi All,

This fix doesn't work with binutils-2.18. I'm building u-boot for the amcc yosemite board using cygwin and cross binutils-2.18/gcc-4.2.2 for a powerpc-eabi target.

Yes, binutils-2.18 have this broken. binutils-2.17 work fine.

In the latest binutils-snapshot (at least):

$ ld -v
GNU ld (GNU Binutils) 2.18.50.20071212

this problem was fixed by:
http://sourceware.org/ml/binutils/2007-11/msg00235.html

U-Boot
commit 41be969f4957115ed7b1fe8b890bfaee99d7a7a2

Author: Wolfgang Denk <[email protected]>
Date:   Thu Dec 6 10:21:19 2007 +0100
     Release v1.3.1

compiled a $ make TQM8540_config target with gcc-4.2.2 within an native mpc8540 environment.

I cannot run-test now, but I will close binutils bug 5205 now:
http://www.sourceware.org/bugzilla/show_bug.cgi?id=5205

Thanks for the detailed report to Brian and for the fix to Nathan. :-)

Regards,

Signature · 10 lines
Clemens Koller
__________________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Stra?e 45/1
Linhof Werksgel?nde
D-81379 M?nchen
Tel.089-741518-50
Fax 089-741518-19
http://www.anagramm-technology.com
author Applied
#5 lore raw

PATCH 1/1 Fix linker scripts: add NOLOAD atribute to .bss/.sbss sections

In reply to Wolfgang Denk
Quoted 11 lines · In message <[email protected]> you wrote:

With recent toolchain versions, some boards would not build because
or errors like this one (here for ocotea board when building with
ELDK 4.2):
ppc_4xx-ld: section .bootpg [fffff000 -> fffff23b] overlaps section .bss [fffee900 -> fffff8ab]

For many boards, the .bss section is big enough that it wraps around at the end of the address space (0xFFFFFFFF), so the problem will not be visible unless you use a 64 bit tool chain for development. On some boards however, changes to the code size (due to different optimizations) we bail out with section overlaps like above.

Quoted 5 lines

The fix is to add the NOLOAD attribute to the .bss and .sbss sections, telling the linker that .bss does not consume any space in the image.

Applied, after re-rworking it for the boards changed, renamed or added meanwhile.

Best regards,

Wolfgang Denk

Signature · 4 lines
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Your own mileage may vary.
#6 lore raw

PATCH 1/1 Fix linker scripts: add NOLOAD atribute to .bss/.sbss sections

Hi Wolfgang,

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

With recent toolchain versions, some boards would not build because or errors like this one (here for ocotea board when building with ELDK 4.2):
ppc_4xx-ld: section .bootpg [fffff000 -> fffff23b] overlaps section .bss [fffee900 -> fffff8ab]

For many boards, the .bss section is big enough that it wraps around at the end of the address space (0xFFFFFFFF), so the problem will not be visible unless you use a 64 bit tool chain for development. On some boards however, changes to the code size (due to different optimizations) we bail out with section overlaps like above.

Quoted 8 lines
Quoted 5 lines

The fix is to add the NOLOAD attribute to the .bss and .sbss sections, telling the linker that .bss does not consume any space in the image.

Applied, after re-rworking it for the boards changed, renamed or added meanwhile.

Thanks. This fixes overlapping problems with bss as seen on Ocotea with ELDK 4.2. But unfortunately I still have other overlapping problems for example on Katmai with ELDK 4.2:

[stefan at ubuntu u-boot (master)]$ ./MAKEALL katmai
Configuring for katmai board...
44x_spd_ddr2.c: In function 'initdram':
44x_spd_ddr2.c:392: warning: 'selected_cas' may be used uninitialized in this function
ppc_4xx-ld: section .bootpg [fffff000 -> fffff377] overlaps section .data.rel.local [ffffeba8 -> fffff3f7]
ppc_4xx-ld: u-boot: section .bootpg lma 0xfffff000 overlaps previous sections
ppc_4xx-ld: u-boot: section .data.rel.ro lma 0xfffff3f8 overlaps previous sections
ppc_4xx-ld: u-boot: section .u_boot_cmd lma 0xfffff408 overlaps previous sections
make: *** [u-boot] Error 1

These error are not seen with ELDK 4.1 by the way. Any ideas what might be causing this and/or how to solve it?

Thanks.

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office at denx.de
=====================================================================

#7 lore raw

[U-Boot-Users] [PPC] PLEASE READ - was: [PATCH] Fix linker scripts: add NOLOAD atribute to .bss/.sbss sections

Dear Stefan,

Quoted 4 lines · in message <[email protected]> you wrote:

Thanks. This fixes overlapping problems with bss as seen on Ocotea with ELDK 4.2. But unfortunately I still have other overlapping problems for example on Katmai with ELDK 4.2:

...

Quoted 4 lines

ppc_4xx-ld: u-boot: section .bootpg lma 0xfffff000 overlaps previous sections
ppc_4xx-ld: u-boot: section .data.rel.ro lma 0xfffff3f8 overlaps previous sections
ppc_4xx-ld: u-boot: section .u_boot_cmd lma 0xfffff408 overlaps previous sections
make: *** [u-boot] Error 1

This problem comes from the fact that the code has become larger when using GCC 4.2.x; this is somewhat a surprise as we all expect more recent versions of the compiler to provide better optimization.

Please see this thread for discussion of the problem:
http://gcc.gnu.org/ml/gcc/2008-01/msg00228.html

Basicly, it comes down to this explanation:

| GCC does not use the load and store multiple instructions because the source
| file declares r29 a global variable:
| 
| register volatile gd_t *gd asm ("r29");
| 
| The bug fix mentioned above inhibits GCC from using lmw/stmw if global
| registers are present in the contiguous register sequence because GCC
| incorrectly would overwrite the register.  If the register variable declaration
| is removed, GCC uses the lmw/stmw instructions.  r29 is a bad choice for a
| global register variable.

So far, it is not clear to me what a better choice for a global register variable could be (i. e. which register we can chose for our purpose without causing the same or other problems.

A possible approach to this problem is to avoid using a global register variable and use a plain global variable instead. The necessary code for this is already there (just commented out); when I implemented this initially, I decided to use a global register variable because it gave slightly smaller code.

Here is an overview of the effect (test build of current top of tree for the "katmai" (PPC440SPe) board):

ELDK Version Register-Var. Globale Var.

	   text    data     bss     dec	      text    data     bss     dec
4.0	 243292   13700  322340  579332	    244160   13808  322340  580308
4.1	 243292   13700  322340  579332     244160   13808  322340  580308

4.2 section ... overlaps previous 245496 13188 322340 581024

As you can see, the difference in code size is less than 1 KiB.

My suggestion is to change the code to use a plain global variable, however I need feedback if we can / want to do that as it effects *ALL* PowerPC boards.

Please comment.

Best regards,

Wolfgang Denk

Signature · 5 lines
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Accident: A condition in which presence of mind is good, but  absence
of body is better.
#8 lore raw

[U-Boot-Users] [PPC] PLEASE READ - was: [PATCH] Fix linker scripts: add NOLOAD atribute to .bss/.sbss sections

Hi Wolfgang,

Quoted 9 lines · Wolfgang Denk

A possible approach to this problem is to avoid using a global register variable and use a plain global variable instead. The necessary code for this is already there (just commented out); when I implemented this initially, I decided to use a global register variable because it gave slightly smaller code.

Here is an overview of the effect (test build of current top of tree for the "katmai" (PPC440SPe) board):

Quoted 7 lines

ELDK Version Register-Var. Globale Var.

	   text    data     bss     dec	      text    data     bss     dec
4.0	 243292   13700  322340  579332	    244160   13808  322340  580308
4.1	 243292   13700  322340  579332     244160   13808  322340  580308

4.2 section ... overlaps previous 245496 13188 322340 581024

As you can see, the difference in code size is less than 1 KiB.

Nice.

Quoted 3 lines

My suggestion is to change the code to use a plain global variable, however I need feedback if we can / want to do that as it effects *ALL* PowerPC boards.

Acked-by for this change from me. I tested successfully on AMCC Katmai, which now fits again in the 256k with GCC 4.2.2.

Thanks.

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office at denx.de
=====================================================================

#9 lore raw

[U-Boot-Users] [PPC] PLEASE READ - was: [PATCH] Fix linker scripts: add NOLOAD atribute to .bss/.sbss sections

In reply to Wolfgang Denk
Quoted 3 lines · Wolfgang Denk

So far, it is not clear to me what a better choice for a global register variable could be (i. e. which register we can chose for our purpose without causing the same or other problems.

r2 is generally used for this purpose.

-Scott

#10 lore raw

[U-Boot-Users] [PPC] PLEASE READ - was: [PATCH] Fix linker scripts: add NOLOAD atribute to .bss/.sbss sections

Quoted 6 lines · In message <[email protected]> you wrote:
Quoted 3 lines · Wolfgang Denk

So far, it is not clear to me what a better choice for a global register variable could be (i. e. which register we can chose for our purpose without causing the same or other problems.

r2 is generally used for this purpose.

Hm... R2 is documented to be the TOC pointer?

It seems we could use R15, but I hesitate a bit...

Best regards,

Wolfgang Denk

Signature · 5 lines
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
The flow chart is a most thoroughly oversold piece of  program  docu-
mentation.              -- Frederick Brooks, "The Mythical Man Month"
#11 lore raw

[U-Boot-Users] [PPC] PLEASE READ - was: [PATCH] Fix linker scripts: add NOLOAD atribute to .bss/.sbss sections

Quoted 8 lines · Wolfgang Denk
Quoted 5 lines · In message <[email protected]> you wrote:
Quoted 3 lines · Wolfgang Denk

So far, it is not clear to me what a better choice for a global register variable could be (i. e. which register we can chose for our purpose without causing the same or other problems.

r2 is generally used for this purpose.

Hm... R2 is documented to be the TOC pointer?

The ABI document says, "Register r2 is reserved for system use and should not be changed by application code."

Linux uses it for the "current" pointer.

-Scott

#12 lore raw

[U-Boot-Users] [PPC] PLEASE READ - was: [PATCH] Fix linker scripts: add NOLOAD atribute to .bss/.sbss sections

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

Hm... R2 is documented to be the TOC pointer?

The ABI document says, "Register r2 is reserved for system use and should not be changed by application code."

OK, tried this, and seems to work. Well, let's throw it out and see what else it breaks ;-)

Patch posted - my own tests look good, so I will apply it ;-)

Best regards,

Wolfgang Denk

Signature · 5 lines
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
The IQ of the group is the lowest IQ of a member of the group divided
by the number of people in the group.
#13 lore raw

[U-Boot-Users] [PPC] PLEASE READ - was: [PATCH] Fix linker scripts: add NOLOAD atribute to .bss/.sbss sections

Quoted 13 lines

-----Original Message-----
From: u-boot-users-bounces at lists.sourceforge.net [mailto:u-boot-users-bounces at lists.sourceforge.net] On Behalf Of Wolfgang Denk
Sent: den 14 februari 2008 23:19
To: Scott Wood
Cc: u-boot-users at lists.sourceforge.net; Stefan Roese
Subject: Re: [U-Boot-Users] [PPC] PLEASE READ - was: [PATCH] Fix linker scripts: add NOLOAD atribute to .bss/.sbss sections

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

Hm... R2 is documented to be the TOC pointer?

Quoted 7 lines
Quoted 2 lines

The ABI document says, "Register r2 is reserved for system use and should not be changed by application code."

OK, tried this, and seems to work. Well, let's throw it out and see what else it breaks ;-)

Patch posted - my own tests look good, so I will apply it ;-)

Works here too, limited testing though

Jocke

#14 lore raw

[U-Boot-Users] [PPC] PLEASE READ - was: [PATCH] Fix linker scripts: add NOLOAD atribute to .bss/.sbss sections

In reply to Wolfgang Denk
Quoted 11 lines · Wolfgang Denk
Quoted 6 lines · In message <[email protected]> you wrote:
Quoted 3 lines · Wolfgang Denk

So far, it is not clear to me what a better choice for a global register variable could be (i. e. which register we can chose for our purpose without causing the same or other problems.

r2 is generally used for this purpose.

Hm... R2 is documented to be the TOC pointer?

It seems we could use R15, but I hesitate a bit...

I think the register approach is needed if we ever want to make u-boot fully relocateable.

There are a few global data accesses that needs to be fixed before that can happen though. There should not be any global data accesses before relocate_code has done its thing. One of the first things that happens in board_init_f is:

for (init_fnc_ptr = init_sequence; *init_fnc_ptr; ++init_fnc_ptr) {
	if ((*init_fnc_ptr) () != 0) {
		hang ();
	}
}

init_sequence is a global variable.

Is this table really needed? Why not move it inside board_init_f and save some bytes?

The next is access is env_get_char, this probably needs to move into GD.

I figured global data accesses wasn't allowed(other than GD) at all before relocate_code()?

Jocke

#15 lore raw

[U-Boot-Users] [PPC] PLEASE READ - was: [PATCH] Fix linker scripts: add NOLOAD atribute to .bss/.sbss sections

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

I think the register approach is needed if we ever want to make u-boot fully relocateable.

Good point.

Quoted 9 lines

There are a few global data accesses that needs to be fixed before that can happen though. There should not be any global data accesses before relocate_code has done its thing. One of the first things that happens in board_init_f is:

for (init_fnc_ptr = init_sequence; *init_fnc_ptr; ++init_fnc_ptr) {
	if ((*init_fnc_ptr) () != 0) {
		hang ();
	}
}
Quoted 4 lines

init_sequence is a global variable.

Is this table really needed? Why not move it inside board_init_f and save some bytes?

The original idea of the table was that a user could provide (in his board config file) a private version to allow for easy, #ifdef free board specific initialization sequences.

Unfortunately I never found the time or resources to complete this.

Quoted 4 lines

The next is access is env_get_char, this probably needs to move into GD.

I figured global data accesses wasn't allowed(other than GD) at all before relocate_code()?

They are not exactly forbidden, you just have to know exactly what you can expect - i. e., usually they just don't make much sense ;-)

Best regards,

Wolfgang Denk

Signature · 4 lines
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"I refuse to have a battle of wits with an unarmed person."
#16 lore raw

[U-Boot-Users] [PPC] PLEASE READ - was: [PATCH] Fix linker scripts: add NOLOAD atribute to .bss/.sbss sections

Quoted 26 lines

-----Original Message-----
From: wd at denx.de [mailto:wd at denx.de]
Sent: den 6 februari 2008 23:11
To: joakim.tjernlund at transmode.se
Cc: Scott Wood; u-boot-users at lists.sourceforge.net; Stefan Roese
Subject: Re: [U-Boot-Users] [PPC] PLEASE READ - was: [PATCH] Fix linker scripts: add NOLOAD atribute to .bss/.sbss sections

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

I think the register approach is needed if we ever want to make u-boot fully relocateable.

Good point.

Quoted 11 lines

There are a few global data accesses that needs to be fixed before that can happen though. There should not be any global data accesses before relocate_code has done its thing. One of the first things that happens in board_init_f is:

for (init_fnc_ptr = init_sequence; *init_fnc_ptr; ++init_fnc_ptr) {
	if ((*init_fnc_ptr) () != 0) {
		hang ();
	}
}

init_sequence is a global variable.

Quoted 8 lines
Quoted 2 lines

Is this table really needed? Why not move it inside board_init_f and save some bytes?

The original idea of the table was that a user could provide (in his board config file) a private version to allow for easy, #ifdef free board specific initialization sequences.

Unfortunately I never found the time or resources to complete this.

I see, there are a lot of #ifdef in there that can be made more generic to cut down on the #ifdef's to a minimum. I read between the lines that you would not object too much if the table was removed?

Quoted 9 lines
Quoted 6 lines

The next is access is env_get_char, this probably needs to move into GD.

I figured global data accesses wasn't allowed(other than GD) at all before relocate_code()?

They are not exactly forbidden, you just have to know exactly what you can expect - i. e., usually they just don't make much sense ;-)

Yeah, sadly I just noticed that constant strings are referenced via the GOT so you can't print those for PPC if you want to make it relocateable.

Any idea how to avoid GOT references for constant strings?

Jocke

Quoted 4 lines

Best regards,

Wolfgang Denk

#17 lore raw

[U-Boot-Users] [PPC] PLEASE READ - was: [PATCH] Fix linker scripts: add NOLOAD atribute to .bss/.sbss sections

Dear Joakim,

Quoted 10 lines · in message <455f01c8691f$423a7890$c6af69b0$@[email protected]> you wrote:
Quoted 6 lines

The original idea of the table was that a user could provide (in his board config file) a private version to allow for easy, #ifdef free board specific initialization sequences.

Unfortunately I never found the time or resources to complete this.

I see, there are a lot of #ifdef in there that can be made more generic to cut down on the #ifdef's to a minimum. I read between the lines that you would not object too much if the table was removed?

Only if the resulting code does not grow and is readable...

Since nobody else picked up the idea over all the years it seems it's not really needed.

Best regards,

Wolfgang Denk

Signature · 7 lines
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
There are two ways of constructing a software design. One way  is  to
make  it  so  simple that there are obviously no deficiencies and the
other is to make it so complicated that there are  no  obvious  defi-
ciencies.                             - Charles Anthony Richard Hoare
#18 lore raw

[U-Boot-Users] [PPC] PLEASE READ - was: [PATCH] Fix linker scripts: add NOLOAD atribute to .bss/.sbss sections

In reply to Wolfgang Denk
Quoted 2 lines · Wolfgang Denk

A possible approach to this problem is to avoid using a global register variable and use a plain global variable instead.

Sounds like a good idea to me. If the code works, then this would simplify things a great deal. The code that reads and writes the gd_t isn't time-critical anyway.

Signature · 2 lines
Timur Tabi
Linux kernel developer at Freescale
#19 lore raw

[U-Boot-Users] [PPC] PLEASE READ - was: [PATCH] Fix linker scripts: add NOLOAD atribute to .bss/.sbss sections

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

A possible approach to this problem is to avoid using a global register variable and use a plain global variable instead.

Sounds like a good idea to me. If the code works, then this would simplify things a great deal. The code that reads and writes the gd_t isn't time-critical anyway.

Except for the declaration of the variable itself, *nothing* changes. What do you mean would become simpler?

Best regards,

Wolfgang Denk

Signature · 5 lines
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
It is surely a great calamity for  a  human  being  to  have  no  ob-
sessions.                                                - Robert Bly
#20 lore raw

[U-Boot-Users] [PPC] PLEASE READ - was: [PATCH] Fix linker scripts: add NOLOAD atribute to .bss/.sbss sections

Quoted 2 lines · Wolfgang Denk

Except for the declaration of the variable itself, *nothing* changes. What do you mean would become simpler?

A normal global variable is simpler than one that's tied to a specific register, wouldn't you say? I wasn't trying to be that insightful.

Signature · 2 lines
Timur Tabi
Linux kernel developer at Freescale
#21 lore raw

[U-Boot-Users] [PPC] PLEASE READ - was: [PATCH] Fix linker scripts: add NOLOAD atribute to .bss/.sbss sections

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

Except for the declaration of the variable itself, *nothing* changes. What do you mean would become simpler?

A normal global variable is simpler than one that's tied to a specific register, wouldn't you say? I wasn't trying to be that insightful.

No, I wouldn't say that. To me a pointer that can live all the time in a register is simpler than one that lives somewhere in a memory location and has to be loaded for use - you can see this from the code size as well.

Also, it's pretty convenient for debugging, for example when you need to figure out where U-Boot was relocated to in RAM - just add the offset in struct global_data and you have the relocation offset, for example.

Best regards,

Wolfgang Denk

Signature · 6 lines
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
It is impractical for  the  standard  to  attempt  to  constrain  the
behavior  of code that does not obey the constraints of the standard.
                                                          - Doug Gwyn