Many BSPs Fail to link CXX tests

[Joel Sherrill]

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 rtems.org> 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.

> 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.

https://docs.google.com/spreadsheets/d/1XHCUqo6EJC08cKS4EgIRyAGabAhDr-7QbJbhQpVVooc/edit?usp=sharing
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.


--joel


Chris
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20160103/abe8b1da/attachment-0002.html>