Speaking as an FSF maintainer (sorry, can't divulge Red Hat secrets ;), to answer some of the technical questions...
It's our intention that the GCC ABI be compatible with the TI ABI, at least, as best we can (If you discover an incompatibility, report it). We've been testing for cross-linking compatibility between our objects/libraries and theirs. The FSF does not package tools at all - it's up to the distro maintainers and third parties to put together packaged (and potentially supported) versions of the tools. Maintainers are responsible for keeping the sources buildable and working correctly in the "default" build, which in our case is either trunk or release branches, built with other gnu packages (gcc, binutils, gdb, newlib is our standard set). The upstream version of gcc supports 430 and 430X, including high memory. Note that the linker doesn't handle "fill two memory regions with the same type of thing" very well, so optimizing the packing of objects into both ROM spaces may require the user to customize the linker script and/or sources (yes, we provide ways to help do this :) We're not 100% compatible with mspgcc, at least as far as the msp430-specific extensions are concerned. We want to be, though. Our highest priority has been creating a port that is acceptable to upstream, once we're accepted upstream our prioririty will shift to user requests (features, bugs, optimizations, etc). The library we've been using for porting is newlib. Instructions for building the msp430 toolchain are the same as for every other gcc/binutils/newlib toolchain (even on cygwin or mingw). Other libraries should be usable, though, although they may need to be recompiled to use the new ABI, and/or to update the msp430-specific extensions. Personally, I'd rather make it "just work" but it will take time to find, test, and fix all the incompatibilities, which will partly depend on users helping. We have a few ideas for supporting chip-specific headers and linker scripts (at least, by default). I've written a short perl script to read TI's device table, so that's not the problem... the problem is there are SO MANY CHIPS! ;-) We don't think we can put TI's device table in the FSF's repo (license issues) and it's not polite (or maintainable) to check in hundreds of files, so we haven't decided what to do there. I've added some features (ok, one ;) to gas/ld to make it possible to further reduce the memory footprint by eliding "standard" gcc/elf features (like C++ constructor tables) if they're not needed. Turns out there are a lot of these, and each has their own "way", so no easy task there. Part of this can be avoided by using a custom startup that just doesn't bother with these features, but we need them in the "standard" startup in order to test the tools (what's good for our development process isn't always good for real users ;) ------------------------------------------------------------------------------ This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev _______________________________________________ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
