current head don;t compile for mpc52xx based boards
Hello,
actual head doesn;t longer compile for the mpc52xx based digsy_mtc_rev5 board (and a fast check, it seems it is for mp52xx, 8xx, ppc4xx based boards):
[hs at pollux u-boot]$ ./MAKEALL digsy_mtc_rev5
Configuring for digsy_mtc_rev5 - Board: digsy_mtc, Options: DIGSY_REV5 libstubs.o: In function `app_startup':/home/hs/charon/u-boot/examples/standalone/stubs.c:197: undefined reference to __bss_end__' /home/hs/charon/u-boot/examples/standalone/stubs.c:197: undefined reference to __bss_end__' make[1]: *** [hello_world] Fehler 1
make: *** [examples/standalone] Fehler 2
make: *** Warte auf noch nicht beendete Prozesse...
ppc_6xx-size: './u-boot': No such file
--------------------- SUMMARY ---------------------------- Boards compiled: 1
Boards with warnings or errors: 1 ( digsy_mtc_rev5 )
----------------------------------------------------------
[hs at pollux u-boot]$
bisection it a bit shows:
[hs at pollux u-boot]$ git bisect good 44c6e6591cb451ae606f8bde71dd5fb7b4002544 is the first bad commit commit 44c6e6591cb451ae606f8bde71dd5fb7b4002544
Author: Po-Yu Chuang <[email protected]> Date: Tue Mar 1 22:59:59 2011 +0000
rename _end to __bss_end__
Currently, _end is used for end of BSS section. We want _end to mean end of u-boot image, so we rename _end to __bss_end__ first.
:040000 040000 9c41e6ba008d29cdb82ecfadea40f224a9c4771e 05f2d7e2e04bef1988ef537f47e7026e4a88a2a8 M arch :040000 040000 e8a97103de34f63145918cc1f119616c5deb8f22 c81f1ef95f863d263f8da1e80a97fdb8361cfe90 M board :040000 040000 29dc021a9988488c841b89c6bf6fab915584ce22 f6db95bc3432104adc5c993aafd7e410dd8f5d9b M examples :040000 040000 96fa70b40a37090b75e4b66df7d1fb61d120f198 faa9863deb077cfca92d31ec93c4b84a2e3f2e1d M nand_spl :040000 040000 927f744a35280f707a9b03059839e0dca45fecb5 6d7771394e8eb1f184dcb24a96453eadc9306c12 M onenand_ipl
[hs at pollux u-boot]$
If I find time, I look in it, but if somebody has an idea, it would be great!
bye,
Heiko
Signature · 2 lines
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Dear Heiko Schocher,
Quoted 4 lines · In message <[email protected]> you wrote:
actual head doesn;t longer compile for the mpc52xx based
digsy_mtc_rev5board (and a fast check, it seems it is for mp52xx, 8xx, ppc4xx based boards):
I think ALL PowerPC boards are affecte.
Po-Yu Chuang, can you please look into this, it's urgent?
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 Felson's Law: To steal ideas from one person is plagiarism; to steal from many is research.
Hi Heiko and Wolfgang,
Quoted 5 lines · Wolfgang Denk
Quoted 4 lines · In message <[email protected]> you wrote:
actual head doesn;t longer compile for the mpc52xx based
digsy_mtc_rev5board (and a fast check, it seems it is for mp52xx, 8xx, ppc4xx based boards):
Could you use objdump to check what is the symbol name for end of BSS defined by ppc toolchain? I don't have the environment now.
Quoted 3 lines
I think ALL PowerPC boards are affecte.
Po-Yu Chuang, can you please look into this, it's urgent?
It seems that we need to find a symbol name globally accepted by all toolchains of all platform. If we rename it to another name careless, we might get the same problem on another platform. Or maybe we can just rename the one used in standalone examples back to _end?
Any suggestion?
Best regards,
Po-Yu Chuang
RFC PATCH 1/1 Fix build problems caused by "_end" -> "__bss_end__" rename
Commit 44c6e65 "rename _end to __bss_end__ broke building of a large number of systems (at least all PowerPC?):
libstubs.o: In function `app_startup':examples/standalone/stubs.c:197: undefined reference to `__bss_end__'
As a workaround (instead of introducing linker scripts) we can add a --defsym=__bss_end__=_end
---
What I really do not understand is why we don't see the same type of undefined reference errors on ARM? ALso, on ARM we see __bss_end__ and _bss_end__, and __bss_start und __bss_start__ - where are the other names coming from? [On PPC we see only __bss_start and __bss_end__].
examples/standalone/Makefile | 1 + 1 files changed, 1 insertions(+), 0 deletions(-)
examples/standalone/Makefile +1 -0
@@ -96,6 +96,7 @@ $(LIB): $(obj).depend $(LIBOBJS) $(ELF): $(obj)%: $(obj)%.o $(LIB) $(LD) -g -Ttext $(STANDALONE_LOAD_ADDR) \ + --defsym=__bss_end__=_end \ -o $@ -e $(SYM_PREFIX)$(notdir $(<:.o=)) $< $(LIB) \ -L$(gcclibdir) -lgcc
Signature · 1 line
1.7.4
RFC PATCH 1/1 Fix build problems caused by "_end" -> "__bss_end__" rename
Hi Wolfgang,
Quoted 12 lines · Wolfgang Denk
Commit 44c6e65 "rename
_endto__bss_end__broke building of a large number of systems (at least all PowerPC?):libstubs.o: In function `app_startup':
examples/standalone/stubs.c:197: undefined reference to `__bss_end__'As a workaround (instead of introducing linker scripts) we can add a --defsym=__bss_end__=_end
Signed-off-by Wolfgang Denk <[email protected]>Cc Po-Yu Chuang <[email protected]>Cc Albert Aribaud <[email protected]>
Quoted 8 lines
---
What I really do not understand is why we don't see the same type of undefined reference errors on ARM? ?ALso, on ARM we see
__bss_end__and _bss_end__, and__bss_startund__bss_start__- where are the other names coming from? [On PPC we see only__bss_startand__bss_end__].
Do you mean _end here? If there is __bss_end__ on PPC, then there is no problem, right?
Quoted 23 lines
?examples/standalone/Makefile | ? ?1 +
?1 files changed, 1 insertions(+), 0 deletions(-)examples/standalone/Makefile +0
-0@@ -96,6 +96,7 @@ $(LIB): ? ? ? $(obj).depend $(LIBOBJS)?$(ELF):
?$(obj)%: ? ? ? $(obj)%.o $(LIB)
? ? ? ? ? ? ? ?$(LD) -g -Ttext $(STANDALONE_LOAD_ADDR) \
+ ? ? ? ? ? ? ? ? ? ? ? --defsym=__bss_end__=_end \
? ? ? ? ? ? ? ? ? ? ? ?-o $@ -e $(SYM_PREFIX)$(notdir $(<:.o=)) $< $(LIB) \
? ? ? ? ? ? ? ? ? ? ? ?-L$(gcclibdir) -lgcc--
1.7.4_______________________________________________
U-Boot mailing list
U-Boot at lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
RFC PATCH 1/1 Fix build problems caused by "_end" -> "__bss_end__" rename
Dear Po-Yu Chuang,
Quoted 9 lines · In message <[email protected]> you…
Quoted 6 lines
What I really do not understand is why we don't see the same type of undefined reference errors on ARM? =C2=A0ALso, on ARM we see
__bss_end__and _bss_end__, and__bss_startund__bss_start__- where are the other names coming from? [On PPC we see only__bss_startand__bss_end__].Do you mean
_endhere? If there is__bss_end__on PPC, then there is no problem, right?
No, I mean exactly what I wrote. On PPC I do not see any _end (with your previous patch), only the symbols defined in the linker script.
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 "Where humor is concerned there are no standards -- no one can say what is good or bad, although you can be sure that everyone will. - John Kenneth Galbraith
RFC PATCH 1/1 Fix build problems caused by "_end" -> "__bss_end__" rename
Hi Wolfgang,
Quoted 10 lines · Wolfgang Denk
Dear Po-Yu Chuang,
Quoted 7 lines · In message <[email protected]> you…
Quoted 6 lines
What I really do not understand is why we don't see the same type of undefined reference errors on ARM? =C2=A0ALso, on ARM we see
__bss_end__and _bss_end__, and__bss_startund__bss_start__- where are the other names coming from? [On PPC we see only__bss_startand__bss_end__].
Quoted 5 lines
Quoted 2 lines
Do you mean
_endhere? If there is__bss_end__on PPC, then there is no problem, right?No, I mean exactly what I wrote. On PPC I do not see any
_end(with your previous patch), only the symbols defined in the linker script.
All those symbols come from default linker script in one of ${toolchain}/arm-none-linux-gnueabi/lib/ldscripts/armelfb_linux_eabi.*.
It defines __bss_start, __bss_start__, _bss_end__ and __bss_end__. Is ARM the only platform doing this?
Best regards,
Po-Yu Chuang
RFC PATCH 1/1 Fix build problems caused by "_end" -> "__bss_end__" rename
Dear Po-Yu Chuang,
Quoted 9 lines · In message <[email protected]> you…
Quoted 3 lines
No, I mean exactly what I wrote. On PPC I do not see any
_end(with your previous patch), only the symbols defined in the linker script.All those symbols come from default linker script in one of ${toolchain}/arm-none-linux-gnueabi/lib/ldscripts/armelfb_linux_eabi.*.
It defines
__bss_start,__bss_start__, _bss_end__ and__bss_end__. Is ARM the only platform doing this?
No. Not even ARM is doing this in general. It's your specific tool chain that does it this way.
It appears that ARM has both *bss_start* and *bss_end*, while PPC has only __bss_start (and __sbss_start and ___sbss_start), but no *bss_end (there are __sbss_end and ___sbss_end, though).
I have no idea if there is any rationale for this inconsistency or if it's a bug.
Verified with both ELDK 4.2 and recent Yocto/Poky tool chains.
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
I think there's a world market for about five computers.
-- attr. Thomas J. Watson (Chairman of the Board, IBM), 1943RFC PATCH 1/1 Fix build problems caused by "_end" -> "__bss_end__" rename
In reply to Wolfgang DenkLe 28/03/2011 10:40, Wolfgang Denk a ?crit :
Quoted 6 lines
Commit 44c6e65 "rename
_endto__bss_end__broke building of a large number of systems (at least all PowerPC?):libstubs.o: In function `app_startup':
examples/standalone/stubs.c:197: undefined reference to `__bss_end__'
Quoted 7 lines
As a workaround (instead of introducing linker scripts) we can add a --defsym=__bss_end__=_end
Signed-off-by Wolfgang Denk<[email protected]>Cc Po-Yu Chuang<[email protected]>Cc Albert Aribaud<[email protected]>---
Hmm... The change from _end to __bss_end__ should not have been applied to the standalone apps, I believe. They are not compiled with start.S but with the standard lib, which will use _end.
Quoted 5 lines
What I really do not understand is why we don't see the same type of undefined reference errors on ARM? ALso, on ARM we see
__bss_end__and _bss_end__, and__bss_startund__bss_start__- where are the other names coming from? [On PPC we see only__bss_startand__bss_end__].
I believe these come from the toolchain's standard lib.
Amicalement,
Signature · 1 line
Albert.
RFC PATCH 1/1 Fix build problems caused by "_end" -> "__bss_end__" rename
Dear Albert ARIBAUD,
Quoted 6 lines · In message <[email protected]> you wrote:
Quoted 6 lines
Commit 44c6e65 "rename
_endto__bss_end__broke building of a large number of systems (at least all PowerPC?):libstubs.o: In function `app_startup':
examples/standalone/stubs.c:197: undefined reference to `__bss_end__'
...
Quoted 3 lines
Hmm... The change from
_endto__bss_end__should not have been applied to the standalone apps, I believe. They are not compiled withstart.Sbut with the standard lib, which will use_end.
Good point. Will send an updated patch.
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
Any sufficiently advanced bug is indistinguishable from a feature.
- Rich KulawiecRFC PATCH v2 1/1 Fix build problems caused by "_end" -> "__bss_end__" rename
In reply to Albert ARIBAUDCommit 44c6e65 "rename _end to __bss_end__ broke building of a large number of systems (at least all PowerPC?):
libstubs.o: In function `app_startup':examples/standalone/stubs.c:197: undefined reference to `__bss_end__'
The rename should not be done for the files in the examples/standalone/ directory, as these are not using the code from start.S, but do their own BSS clearing, and either use their own linker scripts or the ones provided by the compilers.
---
V2: Instead of messing with linker defines, revert the patch in
question for the files in examples/standalone/ as suggested by Albert Aribaud. (Thanks!)
examples/standalone/mips.lds | 2 +- examples/standalone/sparc.lds | 2 +- examples/standalone/stubs.c | 4 ++-- 3 files changed, 4 insertions(+), 4 deletions(-)
examples/standalone/mips.lds +1 -1
@@ -55,5 +55,5 @@ SECTIONS .sbss (NOLOAD) : { *(.sbss) } .bss (NOLOAD) : { *(.bss) . = ALIGN(4); } - __bss_end__ = .; + _end = .; }
examples/standalone/sparc.lds +1 -1
@@ -57,5 +57,5 @@ SECTIONS } . = ALIGN(4); __bss_end = .; - __bss_end__ = .; + _end = .; }
examples/standalone/stubs.c +2 -2
@@ -187,14 +187,14 @@ void __attribute__((unused)) dummy(void)#include <_exports.h> } -extern unsigned long __bss_start, __bss_end__; +extern unsigned long __bss_start, _end;void app_startup (char *const *argv) {unsigned char * cp = (unsigned char *) &__bss_start;/* Zero out BSS */ -while (cp < (unsigned char *)&__bss_end__) { +while (cp < (unsigned char *)&_end) { *cp++ =0 ; }
Signature · 1 line
1.7.4
RFC PATCH v2 1/1 Fix build problems caused by "_end" -> "__bss_end__" rename
Dear Po-Yu Chuang,
Quoted 11 lines · In message <[email protected]> I wrote:
Commit 44c6e65 "rename
_endto__bss_end__broke building of a large number of systems (at least all PowerPC?):libstubs.o: In function `app_startup':
examples/standalone/stubs.c:197: undefined reference to `__bss_end__'The rename should not be done for the files in the examples/standalone/ directory, as these are not using the code from
start.S, but do their own BSS clearing, and either use their own linker scripts or the ones provided by the compilers.
Quoted 5 lines
Signed-off-by Wolfgang Denk <[email protected]>---
V2: Instead of messing with linker defines, revert the patch in
question for the files in examples/standalone/ as suggested by Albert Aribaud. (Thanks!)
Only now I realize that you submitted the very same patch before. Stupid me.
Does that mean that we have an agreement that this hould be the fix then? If yes, I would like to pull this in (Po-Yu Chuang's patch, that is).
Do you agree?
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 A weak mind is like a microscope, which magnifies trifling things, but cannot receive great ones. -- Philip Earl of Chesterfield
RFC PATCH v2 1/1 Fix build problems caused by "_end" -> "__bss_end__" rename
Hi Wolfgang,
Quoted 20 lines · Wolfgang Denk
Dear Po-Yu Chuang,
Quoted 11 lines · In message <[email protected]> I wrote:
Commit 44c6e65 "rename
_endto__bss_end__broke building of a large number of systems (at least all PowerPC?):libstubs.o: In function `app_startup':
examples/standalone/stubs.c:197: undefined reference to `__bss_end__'The rename should not be done for the files in the examples/standalone/ directory, as these are not using the code from
start.S, but do their own BSS clearing, and either use their own linker scripts or the ones provided by the compilers.Quoted 5 lines
Signed-off-by Wolfgang Denk <[email protected]>---
V2: ? Instead of messing with linker defines, revert the patch in ? ? ? question for the files in examples/standalone/ as suggested by ? ? ? Albert Aribaud. (Thanks!)
Quoted 8 lines
Only now I realize that you submitted the very same patch before. Stupid me.
Does that mean that we have an agreement that this hould be the fix then? ?If yes, I would like to pull this in (Po-Yu Chuang's patch, that is).
Do you agree?
Your commit message is better. Please just use your v2 as is. :-)
Thanks,
Po-Yu Chuang
RFC PATCH v2 1/1 Fix build problems caused by "_end" -> "__bss_end__" rename
Quoted 26 lines · Po-Yu Chuang
Hi Wolfgang,
Quoted 23 lines · Wolfgang Denk
Dear Po-Yu Chuang,
Quoted 11 lines · In message <[email protected]> I wrote:
Commit 44c6e65 "rename
_endto__bss_end__broke building of a large number of systems (at least all PowerPC?):libstubs.o: In function `app_startup':
examples/standalone/stubs.c:197: undefined reference to `__bss_end__'The rename should not be done for the files in the examples/standalone/ directory, as these are not using the code from
start.S, but do their own BSS clearing, and either use their own linker scripts or the ones provided by the compilers.Quoted 5 lines
Signed-off-by Wolfgang Denk <[email protected]>---
V2: Instead of messing with linker defines, revert the patch in
question for the files in examples/standalone/ as suggested by Albert Aribaud. (Thanks!)Only now I realize that you submitted the very same patch before. Stupid me.
Quoted 7 lines
Quoted 5 lines
Does that mean that we have an agreement that this hould be the fix then? If yes, I would like to pull this in (Po-Yu Chuang's patch, that is).
Do you agree?
Your commit message is better. Please just use your v2 as is. :-)
We putting this into the tree, would be nice to have builds working again ;)
- k
RFC PATCH 1/1 rename __bss_end__ back to _end for standalone programs
In reply to Po-Yu ChuangFrom: Po-Yu Chuang <[email protected]>
It seems __bss_end__ is not a true convention for all toolchains, at least not for PPC. Using _end for standalone programs might be the simplest way to fix this problem.
One of the other choices may be writing a linker script to provide __bss_end__ for PPC.
---
Hi all,
Not sure if this is the best solution, but I think this could fix Heiko's problem.
examples/standalone/mips.lds | 2 +- examples/standalone/sparc.lds | 2 +- examples/standalone/stubs.c | 4 ++-- 3 files changed, 4 insertions(+), 4 deletions(-)
examples/standalone/mips.lds +1 -1
@@ -55,5 +55,5 @@ SECTIONS .sbss (NOLOAD) : { *(.sbss) } .bss (NOLOAD) : { *(.bss) . = ALIGN(4); } - __bss_end__ = .; + _end = .; }
examples/standalone/sparc.lds +1 -1
@@ -57,5 +57,5 @@ SECTIONS } . = ALIGN(4); __bss_end = .; - __bss_end__ = .; + _end = .; }
examples/standalone/stubs.c +2 -2
@@ -187,14 +187,14 @@ void __attribute__((unused)) dummy(void)#include <_exports.h> } -extern unsigned long __bss_start, __bss_end__; +extern unsigned long __bss_start, _end;void app_startup (char *const *argv) {unsigned char * cp = (unsigned char *) &__bss_start;/* Zero out BSS */ -while (cp < (unsigned char *)&__bss_end__) { +while (cp < (unsigned char *)&_end) { *cp++ =0 ; }
Signature · 1 line
1.6.3.3
Wolfgang Denk
AppliedRFC PATCH 1/1 rename __bss_end__ back to _end for standalone programs
Dear Po-Yu Chuang,
Quoted 13 lines · In message <[email protected]> you…
From: Po-Yu Chuang <[email protected]>
It seems
__bss_end__is not a true convention for all toolchains, at least not for PPC. Using_endfor standalone programs might be the simplest way to fix this problem.One of the other choices may be writing a linker script to provide
__bss_end__for PPC.Signed-off-by Po-Yu Chuang <[email protected]>---
Hi all,
Quoted 7 lines
Not sure if this is the best solution, but I think this could fix Heiko's problem.
examples/standalone/mips.lds | 2 +- examples/standalone/sparc.lds | 2 +- examples/standalone/stubs.c | 4 ++-- 3 files changed, 4 insertions(+), 4 deletions(-)
Applied, with updated changelog as discussed. Thanks.
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 Objects in mirror are closer than they appear.
Dear Po-Yu Chuang,
Quoted 3 lines · In message <[email protected]> you…
Could you use objdump to check what is the symbol name for end of BSS defined by ppc toolchain? I don't have the environment now.
It appears there is no default value used - we get what we define in the linker scripts, and (apparently) nothing else.
Quoted 4 lines
It seems that we need to find a symbol name globally accepted by all toolchains of all platform. If we rename it to another name careless, we might get the same problem on another platform. Or maybe we can just rename the one used in standalone examples back to
_end?
I don;t really understand what's going on there on ARM - see my RC patch.
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 One of the advantages of being a captain is being able to ask for ad- vice without necessarily having to take it. -- Kirk, "Dagger of the Mind", stardate 2715.2