Many BSPs Fail to link CXX tests

Chris Johns chrisj at
Mon Jan 4 01:48:16 UTC 2016

On 01/04/16 12:33, Joel Sherrill wrote:
> Replied from the wrong email address and it didn't go to the list. :(
> Besides this is a longer reply with a reference to a spreadsheet with
> size data for when I turned this on for the sparc BSPs.
> On Sun, Jan 3, 2016 at 6:24 PM, Chris Johns <chrisj at
> <mailto:chrisj at>> wrote:
>     On 12/27/15 02:39, Joel Sherrill wrote:
>         I noticed in a build of all BSPs that a number have trouble
>         linking some of the larger tests. Rather than add them to
>         the tcfg files, is it time to turn on per-function/data item
>         linking to all the BSPs?
>     Does this work for architectures?
> Technically I have no idea. But I think so since this should be a
> generic binutils/ld feature. If it doesn't work on a particular
> architecture, that would be a tools bug to report upstream. And we
> obviously wouldn't use it on that architecture.

This makes sense.

>  > For C++ this makes sense but does it for C?
> Yep. C++ really needs this.
>  > We have worked hard to break down our code into small pieces to
> ensure we link only what is needed. My concern is per-function linking
> relaxes this but it is important?. It becomes difficult to avoid doing
> this if it is supported by an architecture because it works on all code
> including 3rd party libraries which is a huge win.
> When I experimented with doing this on the SPARC BSPs, I saw a large
> drop in test executable sizes drop about 50% on average. So it does make
> difference on C,  I found the spreadsheet I built for SPARC/SIS with and
> without using the per function and data item sections. I apparently did
> this in April 2013.
> It looked like the tests were regularly 45-50% smaller. Even minimum
> dropped.
> Overall, I was quite shocked at how effective it was. I really wanted to
> sweep it across all then. But I am a bit concerned that it breaks
> something. I am now more cynical. If we break it and someone reports it,
> we know of a user. If no one ever says anything, then we either didn't
> break it or no one is using it. Either way, it is information and a
> point in time we can use as a reference for future deprecation of BSPs.

Excellent and I agree. It is a nice feature and I agree we should use it.


More information about the devel mailing list