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 <chr...@rtems.org
<mailto:chr...@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.
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.
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.
Excellent and I agree. It is a nice feature and I agree we should use it.
Chris
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
