On Tue, Apr 25, 2017 at 05:59:43PM +0800, Chen-Yu Tsai wrote: > On Tue, Apr 25, 2017 at 4:46 PM, Chen-Yu Tsai <w...@csie.org> wrote: > > Hi, > > > > On Tue, Apr 25, 2017 at 1:56 PM, Jagan Teki <jagannadh.t...@gmail.com> > > wrote: > >> Hi, > >> > >> We're unable to build with buildman with gcc-4.9.x > >> > >> arm: + Bananapi_M2_Ultra > >> +arm-unknown-linux-gnueabi-ld.bfd: u-boot-spl section `.rodata' will > >> not fit in region `.sram' > >> +arm-unknown-linux-gnueabi-ld.bfd: region `.sram' overflowed by 716 bytes > >> +make[2]: *** [spl/u-boot-spl] Error 1 > >> +make[1]: *** [spl/u-boot-spl] Error 2 > >> > >> Any inputs? > > > > CC-ing Andre as he's probably interested in this as well. > > > > I normally build my stuff with Debian's 6.3 cross compiler. It seems > > that people don't always use the latest stuff, So I did a comparison > > between Linaro's 2016.02 5.3 and 2016.11 6.2.1 toolchains. I don't > > have a 4.x toolchain at the moment. > > > > Long story short, the latter builds successfully, while the former fails. > > However, the object file sizes don't vary much between the two. I think > > the real difference is that the 6.2.1 toolchain comes with the GOLD linker. > > It probably does a much better job at pruning out dead code. > > > > Appended is a list of object file sizes for the 5.3 toolchain, with > > total sizes for the 6.2.1 toolchain for comparison. > > > > A few things pop up: > > > > - spl/arch/arm/lib/interrupts.o > > We are not using interrupts at all. Is this even necessary? > > IIRC there was a patch to get rid of this from Tom (CC-ed). > > > > - spl/common/dlmalloc.o > > Why do we still need this when we have SYS_MALLOC_SIMPLE > > enabled? > > > > - spl/common/image.o > > Almost half of this is description strings for U-boot legacy > > images, which probably isn't used in SPL? Could we somehow > > use macros to get rid of them? > > Digging a bit deeper, I found that interrupts and dlmalloc were > discarded by the linker. As far as C strings go, GCC 5.3 just > dumps them all in the same section, which basically means all of > them will get included, regardless of whether they are actually > used or referenced. GCC 6 does a good job of splitting them by > function, so all the C strings in one function get allocated to > one section. If a function isn't used, it's text and rodata > sections get dropped. > > In a project I worked on in the past, a solution (or workaround) > for this was to use named array (not pointer) symbols for each > string. Each string would get tied to a symbol, and -fdata-sections > would work properly with these. > > IMHO upgrading to a newer toolchain is easier though.
Right and agreed. This is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54303 which was resolved with gcc-6.x. That we keep hitting this form of problem (board X is OK with gcc-6.x or later, fails to link with older) is why I finally did https://patchwork.ozlabs.org/patch/751309/ and have moved travis-ci over to gcc-6.3.1 for ARM. I will be applying my patch for this release. This in turn leads to needing to address lots of new warnings, and I need to find some time to add a real testcase to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80428 as that is the bug I filed over the warnings about "tab_seq[]" and "erase_seq[]" in cli_readline.c -- Tom
signature.asc
Description: Digital signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
