This is the mail archive of the crossgcc@sources.redhat.com mailing list for the crossgcc project.

See the CrossGCC FAQ for lots more information.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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


------ Want more information? See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/ Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]