Re: M0 and M3 patches in linaro toolchains

On 19 August 2013 15:04, Wookey <wookey-Xpnwy/[email protected]> 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
[email protected]