[U-Boot] [PATCH] powerpc/nand spl: link libgcc
Recent GCC (4.4+) performs out-of-line epilogues in some cases, when optimizing for size. It causes a link error for _restgpr_30_x (and similar) if libgcc is not linked.
It actually increases size with very small binaries, due to the fixed size of the out-of-line code, and not having any functions that actually need to restore more than 2 or 3 registers. But I don't see a way to turn it off, other than asking GCC to optimize for speed -- which may also increase size for some boards.
Signed-off-by: Scott Wood scottwood@freescale.com --- nand_spl/board/amcc/acadia/Makefile | 2 +- nand_spl/board/amcc/bamboo/Makefile | 2 +- nand_spl/board/amcc/canyonlands/Makefile | 2 +- nand_spl/board/amcc/kilauea/Makefile | 2 +- nand_spl/board/amcc/sequoia/Makefile | 2 +- nand_spl/board/freescale/mpc8313erdb/Makefile | 2 +- nand_spl/board/freescale/mpc8315erdb/Makefile | 2 +- nand_spl/board/sheldon/simpc8313/Makefile | 2 +- 8 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/nand_spl/board/amcc/acadia/Makefile b/nand_spl/board/amcc/acadia/Makefile index bee24bc..f8ca654 100644 --- a/nand_spl/board/amcc/acadia/Makefile +++ b/nand_spl/board/amcc/acadia/Makefile @@ -51,7 +51,7 @@ $(nandobj)u-boot-spl.bin: $(nandobj)u-boot-spl $(OBJCOPY) ${OBJCFLAGS} -O binary $< $@
$(nandobj)u-boot-spl: $(OBJS) $(nandobj)u-boot.lds - cd $(LNDIR) && $(LD) $(LDFLAGS) $(__OBJS) \ + cd $(LNDIR) && $(LD) $(LDFLAGS) $(__OBJS) $(PLATFORM_LIBS) \ -Map $(nandobj)u-boot-spl.map \ -o $(nandobj)u-boot-spl
diff --git a/nand_spl/board/amcc/bamboo/Makefile b/nand_spl/board/amcc/bamboo/Makefile index 0288c58..438dfbf 100644 --- a/nand_spl/board/amcc/bamboo/Makefile +++ b/nand_spl/board/amcc/bamboo/Makefile @@ -50,7 +50,7 @@ $(nandobj)u-boot-spl.bin: $(nandobj)u-boot-spl $(OBJCOPY) ${OBJCFLAGS} -O binary $< $@
$(nandobj)u-boot-spl: $(OBJS) $(nandobj)u-boot.lds - cd $(LNDIR) && $(LD) $(LDFLAGS) $(__OBJS) \ + cd $(LNDIR) && $(LD) $(LDFLAGS) $(__OBJS) $(PLATFORM_LIBS) \ -Map $(nandobj)u-boot-spl.map \ -o $(nandobj)u-boot-spl
diff --git a/nand_spl/board/amcc/canyonlands/Makefile b/nand_spl/board/amcc/canyonlands/Makefile index ab98d6f..40034e1 100644 --- a/nand_spl/board/amcc/canyonlands/Makefile +++ b/nand_spl/board/amcc/canyonlands/Makefile @@ -55,7 +55,7 @@ $(nandobj)u-boot-spl.bin: $(nandobj)u-boot-spl $(OBJCOPY) ${OBJCFLAGS} -O binary $< $@
$(nandobj)u-boot-spl: $(OBJS) $(nandobj)u-boot.lds - cd $(LNDIR) && $(LD) $(LDFLAGS) $(__OBJS) \ + cd $(LNDIR) && $(LD) $(LDFLAGS) $(__OBJS) $(PLATFORM_LIBS) \ -Map $(nandobj)u-boot-spl.map \ -o $(nandobj)u-boot-spl
diff --git a/nand_spl/board/amcc/kilauea/Makefile b/nand_spl/board/amcc/kilauea/Makefile index 78c67a2..3835f3f 100644 --- a/nand_spl/board/amcc/kilauea/Makefile +++ b/nand_spl/board/amcc/kilauea/Makefile @@ -50,7 +50,7 @@ $(nandobj)u-boot-spl.bin: $(nandobj)u-boot-spl $(OBJCOPY) ${OBJCFLAGS} -O binary $< $@
$(nandobj)u-boot-spl: $(OBJS) $(nandobj)u-boot.lds - cd $(LNDIR) && $(LD) $(LDFLAGS) $(__OBJS) \ + cd $(LNDIR) && $(LD) $(LDFLAGS) $(__OBJS) $(PLATFORM_LIBS) \ -Map $(nandobj)u-boot-spl.map \ -o $(nandobj)u-boot-spl
diff --git a/nand_spl/board/amcc/sequoia/Makefile b/nand_spl/board/amcc/sequoia/Makefile index d3e28ce..9120f15 100644 --- a/nand_spl/board/amcc/sequoia/Makefile +++ b/nand_spl/board/amcc/sequoia/Makefile @@ -50,7 +50,7 @@ $(nandobj)u-boot-spl.bin: $(nandobj)u-boot-spl $(OBJCOPY) ${OBJCFLAGS} -O binary $< $@
$(nandobj)u-boot-spl: $(OBJS) $(nandobj)u-boot.lds - cd $(LNDIR) && $(LD) $(LDFLAGS) $(__OBJS) \ + cd $(LNDIR) && $(LD) $(LDFLAGS) $(__OBJS) $(PLATFORM_LIBS) \ -Map $(nandobj)u-boot-spl.map \ -o $(nandobj)u-boot-spl
diff --git a/nand_spl/board/freescale/mpc8313erdb/Makefile b/nand_spl/board/freescale/mpc8313erdb/Makefile index 88c15a4..cf81099 100644 --- a/nand_spl/board/freescale/mpc8313erdb/Makefile +++ b/nand_spl/board/freescale/mpc8313erdb/Makefile @@ -55,7 +55,7 @@ $(nandobj)u-boot-spl.bin: $(nandobj)u-boot-spl $(OBJCOPY) ${OBJCFLAGS} -O binary $< $@
$(nandobj)u-boot-spl: $(OBJS) $(nandobj)u-boot.lds - cd $(LNDIR) && $(LD) $(LDFLAGS) $(__OBJS) \ + cd $(LNDIR) && $(LD) $(LDFLAGS) $(__OBJS) $(PLATFORM_LIBS) \ -Map $(nandobj)u-boot-spl.map \ -o $(nandobj)u-boot-spl
diff --git a/nand_spl/board/freescale/mpc8315erdb/Makefile b/nand_spl/board/freescale/mpc8315erdb/Makefile index 88c15a4..cf81099 100644 --- a/nand_spl/board/freescale/mpc8315erdb/Makefile +++ b/nand_spl/board/freescale/mpc8315erdb/Makefile @@ -55,7 +55,7 @@ $(nandobj)u-boot-spl.bin: $(nandobj)u-boot-spl $(OBJCOPY) ${OBJCFLAGS} -O binary $< $@
$(nandobj)u-boot-spl: $(OBJS) $(nandobj)u-boot.lds - cd $(LNDIR) && $(LD) $(LDFLAGS) $(__OBJS) \ + cd $(LNDIR) && $(LD) $(LDFLAGS) $(__OBJS) $(PLATFORM_LIBS) \ -Map $(nandobj)u-boot-spl.map \ -o $(nandobj)u-boot-spl
diff --git a/nand_spl/board/sheldon/simpc8313/Makefile b/nand_spl/board/sheldon/simpc8313/Makefile index 86e5ecb..bc6dc65 100644 --- a/nand_spl/board/sheldon/simpc8313/Makefile +++ b/nand_spl/board/sheldon/simpc8313/Makefile @@ -55,7 +55,7 @@ $(nandobj)u-boot-spl.bin: $(nandobj)u-boot-spl $(OBJCOPY) ${OBJCFLAGS} -O binary $< $@
$(nandobj)u-boot-spl: $(OBJS) $(nandobj)u-boot.lds - cd $(LNDIR) && $(LD) $(LDFLAGS) $(__OBJS) \ + cd $(LNDIR) && $(LD) $(LDFLAGS) $(__OBJS) $(PLATFORM_LIBS) \ -Map $(nandobj)u-boot-spl.map \ -o $(nandobj)u-boot-spl
On Fri, 10 Dec 2010 17:00:51 -0600 Scott Wood scottwood@freescale.com wrote:
Recent GCC (4.4+) performs out-of-line epilogues in some cases, when optimizing for size. It causes a link error for _restgpr_30_x (and similar) if libgcc is not linked.
It actually increases size with very small binaries, due to the fixed size of the out-of-line code, and not having any functions that actually need to restore more than 2 or 3 registers. But I don't see a way to turn it off, other than asking GCC to optimize for speed -- which may also increase size for some boards.
Signed-off-by: Scott Wood scottwood@freescale.com
Stefan, can you please pick this up with my:
Acked-by: Kim Phillips kim.phillips@freescale.com
Thanks,
Kim
On Tuesday 14 December 2010 00:06:11 Kim Phillips wrote:
On Fri, 10 Dec 2010 17:00:51 -0600
Scott Wood scottwood@freescale.com wrote:
Recent GCC (4.4+) performs out-of-line epilogues in some cases, when optimizing for size. It causes a link error for _restgpr_30_x (and similar) if libgcc is not linked.
It actually increases size with very small binaries, due to the fixed size of the out-of-line code, and not having any functions that actually need to restore more than 2 or 3 registers. But I don't see a way to turn it off, other than asking GCC to optimize for speed -- which may also increase size for some boards.
Signed-off-by: Scott Wood scottwood@freescale.com
Stefan, can you please pick this up with my:
Acked-by: Kim Phillips kim.phillips@freescale.com
I can do this if Wolfgang has no objections. So I'll wait a short while and pull it onto next then upstream pushing.
Cheers, 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@denx.de
Dear Stefan Roese,
In message 201012140909.27701.sr@denx.de you wrote:
I can do this if Wolfgang has no objections. So I'll wait a short while and pull it onto next then upstream pushing.
I have no objections:
Acked-by: Wolfgang Denk wd@denx.de
Best regards,
Wolfgang Denk
Dear Scott Wood,
In message 20101210230051.GA30739@udp111988uds.am.freescale.net you wrote:
Recent GCC (4.4+) performs out-of-line epilogues in some cases, when optimizing for size. It causes a link error for _restgpr_30_x (and similar) if libgcc is not linked.
It actually increases size with very small binaries, due to the fixed size of the out-of-line code, and not having any functions that actually need to restore more than 2 or 3 registers. But I don't see a way to turn it off, other than asking GCC to optimize for speed -- which may also increase size for some boards.
Signed-off-by: Scott Wood scottwood@freescale.com
nand_spl/board/amcc/acadia/Makefile | 2 +- nand_spl/board/amcc/bamboo/Makefile | 2 +- nand_spl/board/amcc/canyonlands/Makefile | 2 +- nand_spl/board/amcc/kilauea/Makefile | 2 +- nand_spl/board/amcc/sequoia/Makefile | 2 +- nand_spl/board/freescale/mpc8313erdb/Makefile | 2 +- nand_spl/board/freescale/mpc8315erdb/Makefile | 2 +- nand_spl/board/sheldon/simpc8313/Makefile | 2 +- 8 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/nand_spl/board/amcc/acadia/Makefile b/nand_spl/board/amcc/acadia/Makefile index bee24bc..f8ca654 100644 --- a/nand_spl/board/amcc/acadia/Makefile +++ b/nand_spl/board/amcc/acadia/Makefile @@ -51,7 +51,7 @@ $(nandobj)u-boot-spl.bin: $(nandobj)u-boot-spl $(OBJCOPY) ${OBJCFLAGS} -O binary $< $@
$(nandobj)u-boot-spl: $(OBJS) $(nandobj)u-boot.lds
- cd $(LNDIR) && $(LD) $(LDFLAGS) $(__OBJS) \
- cd $(LNDIR) && $(LD) $(LDFLAGS) $(__OBJS) $(PLATFORM_LIBS) \ -Map $(nandobj)u-boot-spl.map \ -o $(nandobj)u-boot-spl
Just two questions:
Q1: Are we sure that the observed behaviour is intentional, and not eventually unintended behaviour (well, a bug) in the new versions of GCC? In general newer releases are supposed to provide better optimization, but with GCC regressions seem to be more common?
Q2: What happens with older compilers, that don't need this? Is this change a No-Op for these?
Best regards,
Wolfgang Denk
On Tue, 14 Dec 2010 00:16:28 +0100 Wolfgang Denk wd@denx.de wrote:
Just two questions:
Q1: Are we sure that the observed behaviour is intentional, and not eventually unintended behaviour (well, a bug) in the new versions of GCC? In general newer releases are supposed to provide better optimization, but with GCC regressions seem to be more common?
I'm pretty sure it's intentional (though lacking an option to turn it off seems ill-advised). It should reduce code size normally -- it's just that NAND SPL is too small for the savings to overcome the fixed cost of the mechanism. The main U-Boot images do seem to have gotten a bit smaller with 4.5.
Going from 4.3 (doesn't do this) to 4.5 (does do this), I see SPL size increases of between 16 and 112 bytes. None of the boards in this patch went over 4096 bytes. Using -O2 instead of -Os, which disables this "optimization", with 4.5 results in even larger SPLs (with or without this patch).
Q2: What happens with older compilers, that don't need this? Is this change a No-Op for these?
With compilers that don't do this, the symbol references won't be generated, and no part of libgcc.a will be pulled in.
-Scott
On Tuesday 14 December 2010 00:49:20 Scott Wood wrote:
Q2: What happens with older compilers, that don't need this? Is this change a No-Op for these?
With compilers that don't do this, the symbol references won't be generated, and no part of libgcc.a will be pulled in.
I tested with ELDK 4.2 (gcc 4.2.2) and see no code size change with this patch applied.
Cheers, 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@denx.de
participants (4)
-
Kim Phillips -
Scott Wood -
Stefan Roese -
Wolfgang Denk