On 19 August 2013 15:04, Wookey wookey@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