| Message ID | 1303633774-22961-4-git-send-email-Joakim.Tjernlund@transmode.se |
|---|---|
| State | Changes Requested |
| Delegated to: | Wolfgang Denk |
| Headers | show |
Dear Joakim Tjernlund, In message <1303633774-22961-4-git-send-email-Joakim.Tjernlund@transmode.se> you wrote: > Seems like recent linker/fpic changes broke a few 8xx boards. > This makes them build again. > > Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se> > --- > board/LEOX/elpt860/u-boot.lds | 2 +- > board/etx094/u-boot.lds | 2 +- > board/svm_sc8xx/u-boot.lds | 2 +- > board/tqc/tqm8xx/u-boot.lds | 2 ++ > 4 files changed, 5 insertions(+), 3 deletions(-) Sorry, but isn't this just papering over the original problem? In the reverted commit you claimed: -msingle-pic-base is a new gcc option for ppc and it reduces the size of my u-boot with 6-8 KB. While at it, add -fno-jump-tables too to save a few more bytes. This promises to reduce the overall code size, but instead the observation is that it is growing, which is the reson for the build problem on some boards. For example TQM860L (top of tree, with 8c4734e reverted (i. e. your old 39768f7 reapplied) and this patch here applied, I see: text data bss dec hex filename 258663 14676 27228 300567 49617 ./u-boot and 0x00008000 . = DEFINED (env_offset)?env_offset:. *fill* 0x40007d28 0x2d8 00 common/env_embedded.o(.ppcenv*) .ppcenv 0x40008000 0x8000 common/env_embedded.o Without these two changes we have: text data bss dec hex filename 257955 14744 27228 299927 49397 ./u-boot and 670 0x00008000 . = DEFINED (env_offset)?env_offset:. 671 *fill* 0x40007fb4 0x4c 00 672 common/env_embedded.o(.ppcenv*) 673 .ppcenv 0x40008000 0x8000 common/env_embedded.o The gap before the embedded environment which is just 76 bytes without your patches now grows to 728 bytes (i. e. by a factor of nearly 10), and the total image sie grows, too. I will not apply either of these commits - neither the reverted one, nor this additional one, as both of them grow the memory footprint instead of redusing it as you promised in the commit message. Best regards, Wolfgang Denk
Wolfgang Denk <wd@denx.de> wrote on 2011/04/24 22:48:09: > > Dear Joakim Tjernlund, > > In message <1303633774-22961-4-git-send-email-Joakim.Tjernlund@transmode.se> you wrote: > > Seems like recent linker/fpic changes broke a few 8xx boards. > > This makes them build again. > > > > Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se> > > --- > > board/LEOX/elpt860/u-boot.lds | 2 +- > > board/etx094/u-boot.lds | 2 +- > > board/svm_sc8xx/u-boot.lds | 2 +- > > board/tqc/tqm8xx/u-boot.lds | 2 ++ > > 4 files changed, 5 insertions(+), 3 deletions(-) > > Sorry, but isn't this just papering over the original problem? > In the reverted commit you claimed: > > -msingle-pic-base is a new gcc option for ppc and > it reduces the size of my u-boot with 6-8 KB. > While at it, add -fno-jump-tables too to save a > few more bytes. > > This promises to reduce the overall code size, but instead the > observation is that it is growing, which is the reson for the build > problem on some boards. Well, your gcc is different from mine and I know nothing about it as you won't say anything about it. This is what I get: With -msingle-pic-base: ## 4.4.5 has been patched to support msingle-pic-base CROSS_COMPILE=powerpc-4.4.5_softfloat-linux-gnu- ./MAKEALL TQM855L TQM860L Configuring for TQM855L board... text data bss dec hex filename 267022 5284 27200 299506 491f2 ./u-boot Configuring for TQM860L board... text data bss dec hex filename 267043 5284 27200 299527 49207 ./u-boot ##powerpc-softfloat-linux-gnu- is 3.4.6 CROSS_COMPILE=powerpc-softfloat-linux-gnu- ./MAKEALL TQM855L TQM860L Configuring for TQM855L board... u-boot.lds:90 cannot move location counter backwards (from 00000000400081d4 to 0000000040008000) make: *** [u-boot] Error 1 powerpc-softfloat-linux-gnu-size: './u-boot': No such file Configuring for TQM860L board... u-boot.lds:90 cannot move location counter backwards (from 00000000400081e0 to 0000000040008000) make: *** [u-boot] Error 1 powerpc-softfloat-linux-gnu-size: './u-boot': No such file Reverted -msingle-pic-base: CROSS_COMPILE=powerpc-4.4.5_softfloat-linux-gnu- ./MAKEALL TQM855L TQM860L Configuring for TQM855L board... u-boot.lds:75 cannot move location counter backwards (from 40008180 to 40008000) make: *** [u-boot] Error 1 powerpc-4.4.5_softfloat-linux-gnu-size: './u-boot': No such file Configuring for TQM860L board... u-boot.lds:75 cannot move location counter backwards (from 40008190 to 40008000) make: *** [u-boot] Error 1 powerpc-4.4.5_softfloat-linux-gnu-size: './u-boot': No such file CROSS_COMPILE=powerpc-softfloat-linux-gnu- ./MAKEALL TQM855L TQM860L Configuring for TQM855L board... u-boot.lds:90 cannot move location counter backwards (from 00000000400081d4 to 0000000040008000) make: *** [u-boot] Error 1 powerpc-softfloat-linux-gnu-size: './u-boot': No such file Configuring for TQM860L board... u-boot.lds:90 cannot move location counter backwards (from 00000000400081e0 to 0000000040008000) make: *** [u-boot] Error 1 powerpc-softfloat-linux-gnu-size: './u-boot': No such file So I strongly suspect that as soon as you move your gcc version upwards, it will break these boards too. > For example TQM860L (top of tree, with 8c4734e reverted (i. e. your > old 39768f7 reapplied) and this patch here applied, I see: > > text data bss dec hex filename > 258663 14676 27228 300567 49617 ./u-boot > > and > > 0x00008000 . = DEFINED (env_offset)?env_offset:. > *fill* 0x40007d28 0x2d8 00 > common/env_embedded.o(.ppcenv*) > .ppcenv 0x40008000 0x8000 common/env_embedded.o > > Without these two changes we have: > > text data bss dec hex filename > 257955 14744 27228 299927 49397 ./u-boot > > and > > 670 0x00008000 . = DEFINED (env_offset)?env_offset:. > 671 *fill* 0x40007fb4 0x4c 00 > 672 common/env_embedded.o(.ppcenv*) > 673 .ppcenv 0x40008000 0x8000 common/env_embedded.o > > > The gap before the embedded environment which is just 76 bytes > without your patches now grows to 728 bytes (i. e. by a factor of > nearly 10), and the total image sie grows, too. Of course, I had for these boards move something from the small space before the environment as some gcc's produce larger code so the targeted space was too small, something had to give. > > > I will not apply either of these commits - neither the reverted one, > nor this additional one, as both of them grow the memory footprint > instead of redusing it as you promised in the commit message. You should read the commit msg again. It requires a gcc which supports -msingle-pic-base. I still don't know why it broke with your gcc but I suspect it is due to -fno-jump-tables(which is in the msingle-pic-base patch). Seems like that option in your case makes the code bigger. Jocke
Dear Joakim Tjernlund, In message <OF102CC99D.B86B21B6-ONC125787C.007CB439-C125787C.0080F875@transmode.se> you wrote: > > Well, your gcc is different from mine and I know nothing about it as > you won't say anything about it. If in doubt, use ELDK. All examples were compiled with ELDK 4.2 (GCC 4.2.2) for ppc_8xx. > ## 4.4.5 has been patched to support msingle-pic-base > CROSS_COMPILE=powerpc-4.4.5_softfloat-linux-gnu- ./MAKEALL TQM855L TQM860L > Configuring for TQM855L board... > text data bss dec hex filename > 267022 5284 27200 299506 491f2 ./u-boot > Configuring for TQM860L board... > text data bss dec hex filename > 267043 5284 27200 299527 49207 ./u-boot I don't have gcc 4.4.x here for testing. > So I strongly suspect that as soon as you move your gcc version upwards, it will break > these boards too. Yes, but for other reasons. Recent versions of GCC (gcc 4.5.x) cannot be used to build this code at all until they get fixed, as -Os is not working, and the code size explodes completely. See GCC bugs 43810, 48278, and 45053. > > I will not apply either of these commits - neither the reverted one, > > nor this additional one, as both of them grow the memory footprint > > instead of redusing it as you promised in the commit message. > > You should read the commit msg again. It requires a gcc which > supports -msingle-pic-base. As the majority of gcc versions outthere does not support this feature, we are trading a (slight?) advantage for a very limited group against disadvantages for a very large group (probably everyone else but you). > I still don't know why it broke with your gcc but I suspect > it is due to -fno-jump-tables(which is in the msingle-pic-base patch). > Seems like that option in your case makes the code bigger. Indeed. As I cannot see any advantages, I reject this stuff, at least for now. Best regards, Wolfgang Denk
Wolfgang Denk <wd@denx.de> wrote on 2011/04/25 10:35:25: > > Dear Joakim Tjernlund, > > In message <OF102CC99D.B86B21B6-ONC125787C.007CB439-C125787C.0080F875@transmode.se> you wrote: > > > > Well, your gcc is different from mine and I know nothing about it as > > you won't say anything about it. > > If in doubt, use ELDK. All examples were compiled with ELDK 4.2 (GCC > 4.2.2) for ppc_8xx. Have you tried gcc 4.3.x yet? > > > ## 4.4.5 has been patched to support msingle-pic-base > > CROSS_COMPILE=powerpc-4.4.5_softfloat-linux-gnu- ./MAKEALL TQM855L TQM860L > > Configuring for TQM855L board... > > text data bss dec hex filename > > 267022 5284 27200 299506 491f2 ./u-boot > > Configuring for TQM860L board... > > text data bss dec hex filename > > 267043 5284 27200 299527 49207 ./u-boot > > I don't have gcc 4.4.x here for testing. > > > So I strongly suspect that as soon as you move your gcc version upwards, it will break > > these boards too. > > Yes, but for other reasons. Rather for these reasons too :) > > Recent versions of GCC (gcc 4.5.x) cannot be used to build this code > at all until they get fixed, as -Os is not working, and the code size > explodes completely. See GCC bugs 43810, 48278, and 45053. hmm, can't really make out if these TR:s also applies for gcc 4.4.5? There are some hints but I cannot tell for sure. > > > > I will not apply either of these commits - neither the reverted one, > > > nor this additional one, as both of them grow the memory footprint > > > instead of redusing it as you promised in the commit message. > > > > You should read the commit msg again. It requires a gcc which > > supports -msingle-pic-base. > > As the majority of gcc versions outthere does not support this > feature, we are trading a (slight?) advantage for a very limited group > against disadvantages for a very large group (probably everyone else > but you). That will probably change very soon. Gentoo will have -msingle-pic-base in its next gcc bump of 4.4.x and 4.5.x I think the mistake was to include the use of -fno-jump-tables in that patch too. The -msingle-pic-base part should be a NOP to all gcc's that don't have it. > > > I still don't know why it broke with your gcc but I suspect > > it is due to -fno-jump-tables(which is in the msingle-pic-base patch). > > Seems like that option in your case makes the code bigger. > > Indeed. As I cannot see any advantages, I reject this stuff, at least > for now. Indeed? Does that mean you confirmed that -fno-jump-tables was the cause? I can respin the patch without that part if so. Jocke
Dear Joakim Tjernlund, In message <OF522299D7.A02484A0-ONC125787D.003187D6-C125787D.0032F0AF@transmode.se> you wrote: > > > If in doubt, use ELDK. All examples were compiled with ELDK 4.2 (GCC > > 4.2.2) for ppc_8xx. > > Have you tried gcc 4.3.x yet? No, and from the list of bugs I have seen for it (especially for ARM) I will not invest time and efforts on it. > I think the mistake was to include the use of -fno-jump-tables in that > patch too. The -msingle-pic-base part should be a NOP to all gcc's that > don't have it. Maybe. > > > I still don't know why it broke with your gcc but I suspect > > > it is due to -fno-jump-tables(which is in the msingle-pic-base patch). > > > Seems like that option in your case makes the code bigger. > > > > Indeed. As I cannot see any advantages, I reject this stuff, at least > > for now. > > Indeed? Does that mean you confirmed that -fno-jump-tables was the cause? > I can respin the patch without that part if so. The "indeed" refers to the "in my case your patches make the code bigger". I cannot confirm anything else as I haven't tested it. Best regards, Wolfgang Denk
diff --git a/board/LEOX/elpt860/u-boot.lds b/board/LEOX/elpt860/u-boot.lds index 5aaf6b3..37b74ec 100644 --- a/board/LEOX/elpt860/u-boot.lds +++ b/board/LEOX/elpt860/u-boot.lds @@ -43,7 +43,7 @@ SECTIONS arch/powerpc/cpu/mpc8xx/start.o (.text*) arch/powerpc/cpu/mpc8xx/traps.o (.text*) - common/libcommon.o (.text*) + /* common/libcommon.o (.text*) */ arch/powerpc/cpu/mpc8xx/libmpc8xx.o (.text*) board/LEOX/elpt860/libelpt860.o (.text*) arch/powerpc/lib/libpowerpc.o (.text*) diff --git a/board/etx094/u-boot.lds b/board/etx094/u-boot.lds index b68d9ea..33c4dba 100644 --- a/board/etx094/u-boot.lds +++ b/board/etx094/u-boot.lds @@ -36,7 +36,7 @@ SECTIONS arch/powerpc/cpu/mpc8xx/traps.o (.text*) net/libnet.o (.text*) arch/powerpc/cpu/mpc8xx/libmpc8xx.o (.text*) - *(.text.*printf*) + /* *(.text.*printf*) */ . = env_offset; common/env_embedded.o (.text*) diff --git a/board/svm_sc8xx/u-boot.lds b/board/svm_sc8xx/u-boot.lds index c65f022..7b886f0 100644 --- a/board/svm_sc8xx/u-boot.lds +++ b/board/svm_sc8xx/u-boot.lds @@ -41,7 +41,7 @@ SECTIONS *(.text.*printf) *(.text.do_mem_*) *(.text.flash*) - *(.text.run_command) +/* *(.text.run_command) */ *(.text.main_loop) *(.text.srec_decode) diff --git a/board/tqc/tqm8xx/u-boot.lds b/board/tqc/tqm8xx/u-boot.lds index f625c3d..43bfe1c 100644 --- a/board/tqc/tqm8xx/u-boot.lds +++ b/board/tqc/tqm8xx/u-boot.lds @@ -42,8 +42,10 @@ SECTIONS drivers/pcmcia/libpcmcia.o (.text*) drivers/rtc/librtc.o (.text*) drivers/misc/libmisc.o (.text*) +/* *(.text.print_buffer) *(.text.print_size) +*/ . = DEFINED(env_offset) ? env_offset : .; common/env_embedded.o (.ppcenv*)
Seems like recent linker/fpic changes broke a few 8xx boards. This makes them build again. Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se> --- board/LEOX/elpt860/u-boot.lds | 2 +- board/etx094/u-boot.lds | 2 +- board/svm_sc8xx/u-boot.lds | 2 +- board/tqc/tqm8xx/u-boot.lds | 2 ++ 4 files changed, 5 insertions(+), 3 deletions(-)