On 19 August 2013 15:04, Wookey <woo...@wookware.org> wrote: > Debconf13 (last week) considered the matter of bare-metal > cross-toolchains in Debian. Ideally we would have one toolchain source > package from which the existing linux native compilers, and > cross-compilers are built, including bare-metal cross-compilers. There > is already mechanism for adding patches for particular gcc builds, so > so long as the patch set is manageable and trackable, this would be > nice, and futureproof, as eventually the patch set should just > evaporate as it gets upstreamed. > > The alternative it to simply repack the existing linaro > cross-toolchain sources, but them we get to keep doing that for new > releases, and we have gratuitous extra copies of gcc sources and > corresponding differences between A* and M* toolchains/versions. > > The linaro embedded toolchains > (https://launchpad.net/gcc-arm-embedded/4.7/4.7-2013-q1-update) are > good, and work, both for M0 and M3. But building nominally the same > thing from upstream gcc gets something where M3 works but M0 doesn't.
OK - These aren't Linaro owned tools. They are produced by ARM. We link to them to make sure people can find the tools they need. Can you expand (possibly in a separate thread) on "M3 works but M0 doesn't"? I'd expect the gcc-arm-embedded tools to support all M-profile cores out of the box. > Also they are gcc 4.7 based whilst Debian is moving to a 4.8 default. If history is anything to go by there will be a 4.8 release of that toolchain sometime in Q4 2013. > We peered at checkouts from linaro and upstream and tried to work out > what the linaro patch-set for this toolchain is, and exactly where it > branched off upstream, but it was confusing with a lot of noise due to > version skew around some actually relevant changes. > > So, in order to work out if we can in fact build our bare-metal > toolchains from the same sources as the existing toolchains we need to > know what the actual patch-set you are maitaining looks like, and what > is already upstreamed in which gcc branch/release and when the > remaining patches will go upstream. Also what the 4.7 vs 4.8 status > is. Knowing how this stuff is tracked might be even more useful over > the longer term. > > Is there such info online somewhere? If not please elaborate. A > mechanism for keeping the (newly-formed) Debian cross-compiler team > sufficiently in the loop is probably what's needed in the longer term, > unless this is all just about to get upstreamed anyway and the issue > will soon become moot...? The Linaro branch for 4.8 is in the main SVN repository for GCC: svn://gcc.gnu.org/branches/linaro/gcc-4_8-branch And we use svn merge to keep track of merge data. We work by getting patches accepted into trunk and then backporting them - so every substantive patch is a backport from trunk. There are some patches in the Linaro branch which are not also in trunk - but these all relate to release stuff - and so don't make any difference to the code generation. Personally, even if you end up just using the Debian patchset by default (which will not be a terrible starting point), you should take a look at the way the GCC ARM Embedded toolchain configures multilib for bare-metal. These are a good starting point for choosing a set of multilibs to build. Thanks, Matt -- Matthew Gretton-Dann Linaro Toolchain Working Group matthew.gretton-d...@linaro.org _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
