| Message ID | 1336009071-23704-1-git-send-email-cdhmanning@gmail.com |
|---|---|
| State | Deferred |
| Delegated to: | Albert ARIBAUD |
| Headers | show |
On Wednesday 02 May 2012 21:37:51 Charles Manning wrote: > Seems odd that this hasn't been done yet. > Shaves 5k off an omap overo build. my understanding is that it doesn't work for some > +PLATFORM_RELFLAGS += -ffunction-sections where's the -fdata-sections ? -mike
On Monday 14 May 2012 17:15:50 Mike Frysinger wrote: > On Wednesday 02 May 2012 21:37:51 Charles Manning wrote: > > Seems odd that this hasn't been done yet. > > Shaves 5k off an omap overo build. > > my understanding is that it doesn't work for some It won't work for people that don't set up their lds properly. > > > +PLATFORM_RELFLAGS += -ffunction-sections > > where's the -fdata-sections ? I tried that once before and could not get that to work with u-boot. I figure doing just the function sections is better than nothing.
On Monday 14 May 2012 17:01:30 Charles Manning wrote: > On Monday 14 May 2012 17:15:50 Mike Frysinger wrote: > > On Wednesday 02 May 2012 21:37:51 Charles Manning wrote: > > > Seems odd that this hasn't been done yet. > > > Shaves 5k off an omap overo build. > > > > my understanding is that it doesn't work for some > > It won't work for people that don't set up their lds properly. current u-boot policy is to not introduce changes that knowingly break other platforms. so if you want to update the common arm config.mk, you need to at least compile test all arm boards. > > > +PLATFORM_RELFLAGS += -ffunction-sections > > > > where's the -fdata-sections ? > > I tried that once before and could not get that to work with u-boot. I > figure doing just the function sections is better than nothing. so even your lds isn't setup properly ? :P other arches are using both fine, so it isn't a problem of common code. -mike
Le 15/05/2012 07:12, Mike Frysinger a écrit : > On Monday 14 May 2012 17:01:30 Charles Manning wrote: >> On Monday 14 May 2012 17:15:50 Mike Frysinger wrote: >>> On Wednesday 02 May 2012 21:37:51 Charles Manning wrote: >>>> Seems odd that this hasn't been done yet. >>>> Shaves 5k off an omap overo build. >>> >>> my understanding is that it doesn't work for some >> >> It won't work for people that don't set up their lds properly. > > current u-boot policy is to not introduce changes that knowingly break other > platforms. so if you want to update the common arm config.mk, you need to at > least compile test all arm boards. ... and considering this is dependent on toolchain setups, this should also be performed for the most common toolchains versions around (ELDK 4.2 and 5.x; CS 2011, 2010, maybe even 2009; Linaro; LLVM even). >>>> +PLATFORM_RELFLAGS += -ffunction-sections >>> >>> where's the -fdata-sections ? >> >> I tried that once before and could not get that to work with u-boot. I >> figure doing just the function sections is better than nothing. > > so even your lds isn't setup properly ? :P > > other arches are using both fine, so it isn't a problem of common code. > -mike Amicalement,
On Tuesday 15 May 2012 17:12:05 Mike Frysinger wrote: > On Monday 14 May 2012 17:01:30 Charles Manning wrote: > > On Monday 14 May 2012 17:15:50 Mike Frysinger wrote: > > > On Wednesday 02 May 2012 21:37:51 Charles Manning wrote: > > > > Seems odd that this hasn't been done yet. > > > > Shaves 5k off an omap overo build. > > > > > > my understanding is that it doesn't work for some > > > > It won't work for people that don't set up their lds properly. > > current u-boot policy is to not introduce changes that knowingly break > other platforms. so if you want to update the common arm config.mk, you > need to at least compile test all arm boards. Doesn't that makes it an impossible task? Not having all the boards makes it pretty hard to test them all. > > > > > +PLATFORM_RELFLAGS += -ffunction-sections > > > > > > where's the -fdata-sections ? > > > > I tried that once before and could not get that to work with u-boot. I > > figure doing just the function sections is better than nothing. > > so even your lds isn't setup properly ? :P Correct. I was aiming to achieve a certain size. Once I achieved that I stopped fiddling. The problem was probably in the relocation stuff. > > other arches are using both fine, so it isn't a problem of common code. I might be incorrect, but I have noticed what appears to be some differences between different versions of binutils. -- CHarles
Dear Charles, In message <201205161007.59560.manningc2@actrix.gen.nz> you wrote: > On Tuesday 15 May 2012 17:12:05 Mike Frysinger wrote: ... > > current u-boot policy is to not introduce changes that knowingly break > > other platforms. so if you want to update the common arm config.mk, you > > need to at least compile test all arm boards. ---------------------^^^^^^^^^^^^ > Doesn't that makes it an impossible task? Not having all the boards makes it > pretty hard to test them all. A compile test does not require any actual hardware. > > other arches are using both fine, so it isn't a problem of common code. > > I might be incorrect, but I have noticed what appears to be some differences > between different versions of binutils. Please be more specific. The same "different versions of binutils" appear to work fine on other architectures ? Best regards, Wolfgang Denk
On Wednesday 16 May 2012 10:25:26 Wolfgang Denk wrote: > Dear Charles, > > In message <201205161007.59560.manningc2@actrix.gen.nz> you wrote: > > On Tuesday 15 May 2012 17:12:05 Mike Frysinger wrote: > > ... > > > > current u-boot policy is to not introduce changes that knowingly break > > > other platforms. so if you want to update the common arm config.mk, > > > you need to at least compile test all arm boards. > > ---------------------^^^^^^^^^^^^ > > > Doesn't that makes it an impossible task? Not having all the boards makes > > it pretty hard to test them all. > > A compile test does not require any actual hardware. Does the patch fail I submitted fail any compile tests? AFAIK, it compiles but the resulting binary might just be rubbish on some boards. It worked fine on my overo board without any changes to the overo lds. I have just verified that it builds on overo mx51evk davinci_sonata If there is an expectation to build every possible config is there a script that will do that? > > > > other arches are using both fine, so it isn't a problem of common code. > > > > I might be incorrect, but I have noticed what appears to be some > > differences between different versions of binutils. > > Please be more specific. The same "different versions of binutils" > appear to work fine on other architectures ? That was based on some observations a year or two ago. I don't know if the problem has now gone away and have no way of reproducing it. -- Charles
On Wed, May 16, 2012 at 10:45:33AM +1200, Charles Manning wrote: > On Wednesday 16 May 2012 10:25:26 Wolfgang Denk wrote: > > Dear Charles, > > > > In message <201205161007.59560.manningc2@actrix.gen.nz> you wrote: > > > On Tuesday 15 May 2012 17:12:05 Mike Frysinger wrote: > > > > ... > > > > > > current u-boot policy is to not introduce changes that knowingly break > > > > other platforms. so if you want to update the common arm config.mk, > > > > you need to at least compile test all arm boards. > > > > ---------------------^^^^^^^^^^^^ > > > > > Doesn't that makes it an impossible task? Not having all the boards makes > > > it pretty hard to test them all. > > > > A compile test does not require any actual hardware. > > Does the patch fail I submitted fail any compile tests? > > AFAIK, it compiles but the resulting binary might just be rubbish on some > boards. > > It worked fine on my overo board without any changes to the overo lds. > > I have just verified that it builds on > overo > mx51evk > davinci_sonata > > If there is an expectation to build every possible config is there a script > that will do that? Yes, MAKEALL in the top level. Assuming you've installed ELDK5.1 or 4.2 to their default locations: $ source /opt/eldk-5.1/armv7a/environment-setup-armv7a-vfp-neon-linux-gnueabi $ CROSS_COMPILE=arm-linux-gnueabi- BUILD_DIR=eldk51 ./MAKEALL -a arm $ CROSS_COMPILE=/opt/eldk-4.2/arm/usr/bin/arm-linux-gnueabi- BUILD_DIR=eldk42 ./MAKEALL -a arm (I've got the above in a script with a few tweaks to build all TI stuff, for example).
Dear Charles Manning, In message <201205150901.30710.manningc2@actrix.gen.nz> you wrote: > > > > +PLATFORM_RELFLAGS += -ffunction-sections > > > > where's the -fdata-sections ? > > I tried that once before and could not get that to work with u-boot. I figure > doing just the function sections is better than nothing. What exactly do you mean by "could not get that to work"? What exactly was the problem? And which exact tool chain did you use then? Best regards, Wolfgang Denk
diff --git a/arch/arm/config.mk b/arch/arm/config.mk index 45f9dca..73e0cce 100644 --- a/arch/arm/config.mk +++ b/arch/arm/config.mk @@ -55,6 +55,10 @@ PF_CPPFLAGS_ABI := $(call cc-option,\ ) PLATFORM_CPPFLAGS += $(PF_CPPFLAGS_ARM) $(PF_CPPFLAGS_ABI) +PLATFORM_RELFLAGS += -ffunction-sections + +LDFLAGS_FINAL += --gc-sections + # For EABI, make sure to provide raise() ifneq (,$(findstring -mabi=aapcs-linux,$(PLATFORM_CPPFLAGS))) # This file is parsed many times, so the string may get added multiple
Seems odd that this hasn't been done yet. Shaves 5k off an omap overo build. Signed-off-by: Charles Manning <cdhmanning@gmail.com> --- arch/arm/config.mk | 4 ++++ 1 files changed, 4 insertions(+), 0 deletions(-)