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] |
On Sun, Aug 24, 2003 at 10:24:13PM +0200, Vincent Rubiolo wrote: > 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? Not in the configuration I use. > This is because I think the problem might come from here. > I will try to tweak > newlib to build it with -fdata-sections and -ffunction-sections. It should then > give good results. The build configuration for eCos uses -fxxxx-sections and then garbage-collection of sections by ld, and it works well. If a function isn't called by anybody, it isn't included in the final image -- even if other functions in the same object file are required. No more worrying about whether you should put each library function in a seperate source file (which violates encapsulation by requiring a lot of things be global when they should be statically scoped), or group them "logically" into fewer, larger files in order to provide encapsulation and data-hiding (which used to pull in un-needed functions). -- Grant Edwards grante@visi.com ------ 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] |