On 05/08/11 16:38, Grant Edwards wrote: > On 2011-08-05, Peter Bigot<pabi...@users.sourceforge.net> wrote: >> On Fri, Aug 5, 2011 at 12:06 AM, William "Chops" Westfield >> <wes...@mac.com> wrote: >>> >>> On Aug 4, 2011, at 8:18 AM, Peter Bigot wrote: >>> >>>> --gc-sections should now be fixed >>>> ? : >>>> ?Use of "msp430-ar" will work as expected >>> >>> Hmm. ?So is there a tool that will take a source module >>> (with multiple functions) compiled with the relevant compiler >>> options (-ffunction-sections and -fdata-sections) and produce >>> a random-access library of the sort you would have gotten if >>> you had broken down the source to file-per-function? >> >> I personally don't know of such a tool; it seems --gc-sections is the >> way this is need is expected to be met. FWIW, as an experiment I >> added the flags to msp430-libc and it seems to work, though the >> savings is naturally not particularly impressive (90 bytes of a 28KB >> image from a monolithic TinyOS program). > > The benefit is seen mainly when you want to reuse code or build > multiple versions of a program with different features enabled. > > For example, you write a "library" module providing a half-dozen > publically visible functions: it may have another half-dozen private > functions and some private data. > > In a given program you may only use one or two of the public > functions. > > Without --gc-sections you have come up with a set of preprocessor > macros to enable/disable the building of individual public functions. > Then inside the module you need even more complex cpp magic to figure > out which private functions and data are needed based on which public > functions have been enabled. Then you have to re-compile the module > everytime the configuration changes. > > Either that, or you replace your single object file with a dozen plus > object files and you expose all of the module's private data to > everybody and his dog. > > If you're just bulding multiple versions of one program with different > features enabled, --gc-sections allows you to do that without having > to recompile anything -- it's all handled at the link stage. If you > want to build the full-fat version, you link in all the files. If you > don't want features A and B, you don't link in object files A and B. > The linker figures out what other functions/data aren't need now that > A and B have been left out, and those functions get left out as well. >
The best way to handle such situations is using link-time optimisation. I don't know what the state of LTO is with mspgcc, but LTO along with -fwhole-program will do everything you could want with --gc-sections, -ffunction-sections and -fdata-sections, and /much/ more besides. If LTO is working, you should consider --gc-sections and related flags as deprecated. ------------------------------------------------------------------------------ BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos & much more. Register early & save! http://p.sf.net/sfu/rim-blackberry-1 _______________________________________________ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
