[U-Boot] sunxi: Build issue with Bananapi_M2_Ultra

[Tom Rini]

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 <wens at csie.org> wrote:
> > Hi,
> >
> > On Tue, Apr 25, 2017 at 1:56 PM, Jagan Teki <jagannadh.teki at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20170425/1364f8d7/attachment.sig>