Re: arm-elf-gcc : change default data alignement depending on ARM/THUMB

[Vincent Rubiolo <vincent dot rubiolo at st dot com>]

Hello to you all,

Dan :
Sorry not to have mentioned that : I was talking about stripped images and yes 
the difference is huge (unstripped: 1.8 Mb, stripped : 270 kb :)

Bill and Grant :
[...]
> I've recently compared size/performance of an eCos application
> built w/ 2.95.x and with 3.2.x, and I've seen a size reduction
> of about 20% or so, along with a corresponding increase in
> performance.
> The two builds weren't _completely_ identical, but he
> differences shouldnt have been much.
I did not do tests with 2.95.x but the proceedings of the gcc summit about 
optimising for space seem to draw the same conclusions as your do : 3.x is 
better than 2.95.x (doc here : www.linux.org.uk/~ajh/gcc/ 
gccsummit-2003-proceedings.pdf, very interesting but for pure ARM code only)
I am not too familiar about eCos. Is interworking enabled in it? This is because 
I think the problem might come from here.
> > One potential source is runtime libraries.  ADS's library
> > structure is pretty granular, and their linker seems to be
> > pretty good at discarding unused code.  GNU-compatible runtime
> > libraries don't seem to be as fine-grained in their
> > implementation as ADS, so the GNU linker isn't as helpful at
> > keeping unused modules and/or functions out of the resulting
> > image.  Or maybe it's because the GNU linker is more
> > simplistic, and the library architecture isn't the source of
> > the bloat.  Dunno.

Completely agree on that point. The Perl scripts I use to calculate sizes report 
differences for up to 30% in size for runtime libraries. I will try to tweak 
newlib to build it with -fdata-sections and -ffunction-sections. It should then 
give good results.
After having experimented a while with ld, I would not say that it is so 
simplistic : garbage collecting/selective linking is really helpful with 
-ffunction-sections and -fdata-sections, you just have to enable it. The general 
design of ld makes you think about what you want to achieve : ADS linker 
performs certain optimisations for you, ld gives you full control of the linking 
process.

> If you put each function in a separate section, and turn on
> garbage collection in the linker, then the granularity of the
> linking process should be at the function level rather than at
> the object file level.  Without those options enabled, you
> might end up with a fair number of un-needed library functions.
Correct. I enabled such an option last Friday after my previous post and looked 
at the logs during the WE : 5% gain in size! This is very good news since RAM 
usage is really a concern on our system (the gain corresponds to around 2kb). As 
I stated, I will try to build newlib in such a way.

I'll let you know how it goes.

Thanks for all you advices.

Regards,

Vincent