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. Also they are gcc 4.7 based whilst Debian is moving to a 4.8 default. 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...?
There was also discussion around the concept of making existing linux-arm cross-compilers, with M0 and M3 support included, and using spec-file jiggery-pokery to get them to DTRT for M* targets. This should be possible, but advice from anyone who's every actually tried on the gotchas would be good.
cheers
Wookey
Wookey wookey@wookware.org writes:
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.
I'm working on this process at the moment; I figure that having a stable and reliable compiler will provide a good starting point while we sort out how to unify the compiler source code bases.
A simple 'diff' from the linaro q2 release from current Debian 4.7 compiler sources is something over 700k lines at present; dumping that into a package doesn't exactly seem like a good idea.
-keith
Am 19.08.2013 17:27, schrieb Keith Packard:
Wookey wookey@wookware.org writes:
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.
I'm working on this process at the moment; I figure that having a stable and reliable compiler will provide a good starting point while we sort out how to unify the compiler source code bases.
A simple 'diff' from the linaro q2 release from current Debian 4.7 compiler sources is something over 700k lines at present; dumping that into a package doesn't exactly seem like a good idea.
attaching a diff, comparing the two branches at a merge point (r201326), 398 lines.
Matthias
Matthias Klose doko@ubuntu.com writes:
Am 19.08.2013 17:27, schrieb Keith Packard:
Wookey wookey@wookware.org writes:
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.
I'm working on this process at the moment; I figure that having a stable and reliable compiler will provide a good starting point while we sort out how to unify the compiler source code bases.
A simple 'diff' from the linaro q2 release from current Debian 4.7 compiler sources is something over 700k lines at present; dumping that into a package doesn't exactly seem like a good idea.
attaching a diff, comparing the two branches at a merge point (r201326), 398 lines.
Ok, thanks very much for this simple patch. First the good news -- I applied this patch to the 4.8.1 GCC sources included in debian and successfully built a cortex-m0 executable.
The bad news is that the gcc multilib support for arm appears to be broken, at least in this case.
1) When I pass -mthumb -mcpu=cortex-m0 to gcc in the linking phase, the multilib configuration does not point at the thumb directory, and so the linker happily pulls libgcc.a from the arm directory. It looks like the multilib configuration that is generated is just wrong:
static const char *const multilib_raw[] = { ". !mthumb !marm !march=armv6s-m !march=armv7-m !march=armv7e-m !march=armv7 !mfloat-abi=softfp !mfloat-abi=hard !mfpu=fpv4-sp-d16 !mfpu=vfpv3-d16;", "thumb mthumb !marm !march=armv6s-m !march=armv7-m !march=armv7e-m !march=armv7 !mfloat-abi=softfp !mfloat-abi=hard !mfpu=fpv4-sp-d16 !mfpu=vfpv3-d16;", "arm !mthumb marm !march=armv6s-m !march=armv7-m !march=armv7e-m !march=armv7 !mfloat-abi=softfp !mfloat-abi=hard !mfpu=fpv4-sp-d16 !mfpu=vfpv3-d16;", "fpu !mthumb !marm !march=armv6s-m !march=armv7-m !march=armv7e-m !march=armv7 !mfloat-abi=softfp mfloat-abi=hard !mfpu=fpv4-sp-d16 !mfpu=vfpv3-d16;", NULL };
The 'thumb' directory is only selected if the -mthumb option is passed to the compiler *and* none of the thumb architecture flags (-march=armv6s-m for instance) are also passed.
2) The thumb version of libgcc.a is not built with thumb instructions because GCC doesn't pass -mthumb to the assembler when it receives -mthumb on the command line.
3) That's ok, because the GNU assembler doesn't listen to -mthumb anyways; I had to force the assembler to compile thumb instructions by passing it -mcpu=cortex-m0 on the command line to GCC, which is then passed along to the assembler.
Figured you'd like to know what progress I've made, at this point it looks like simple driver bugs. Once resolved, it looks like I'll be able to generate a debian package from the debian GCC sources and a small patch.
-keith
Keith
On 7 October 2013 05:20, Keith Packard keithp@keithp.com wrote:
Matthias Klose doko@ubuntu.com writes:
attaching a diff, comparing the two branches at a merge point (r201326), 398 lines.
Ok, thanks very much for this simple patch. First the good news -- I applied this patch to the 4.8.1 GCC sources included in debian and successfully built a cortex-m0 executable.
The bad news is that the gcc multilib support for arm appears to be broken, at least in this case.
- When I pass -mthumb -mcpu=cortex-m0 to gcc in the linking phase, the multilib configuration does not point at the thumb directory, and so the linker happily pulls libgcc.a from the arm directory. It looks like the multilib configuration that is generated is just wrong:
static const char *const multilib_raw[] = { ". !mthumb !marm !march=armv6s-m !march=armv7-m !march=armv7e-m !march=armv7 !mfloat-abi=softfp !mfloat-abi=hard !mfpu=fpv4-sp-d16 !mfpu=vfpv3-d16;", "thumb mthumb !marm !march=armv6s-m !march=armv7-m !march=armv7e-m !march=armv7 !mfloat-abi=softfp !mfloat-abi=hard !mfpu=fpv4-sp-d16 !mfpu=vfpv3-d16;", "arm !mthumb marm !march=armv6s-m !march=armv7-m !march=armv7e-m !march=armv7 !mfloat-abi=softfp !mfloat-abi=hard !mfpu=fpv4-sp-d16 !mfpu=vfpv3-d16;", "fpu !mthumb !marm !march=armv6s-m !march=armv7-m !march=armv7e-m !march=armv7 !mfloat-abi=softfp mfloat-abi=hard !mfpu=fpv4-sp-d16 !mfpu=vfpv3-d16;", NULL };
Can you please provide the output of: 1. arm-none-eabi-gcc -v 2. arm-none-eabi-gcc -print-multi-lib
My guess is that you've configured GCC using --with-mode=thumb, and other --with-* options. This is usually the wrong thing to do with multilibs.
The other thing to note is you need to specify what multilib architectures you want with --with-multilib-list when you configure: --with-multilib-list=armv6-m,armv7-m,armv7e-m,armv7-a,armv7-r Seems like a good initial try to me.
The 'thumb' directory is only selected if the -mthumb option is passed to the compiler *and* none of the thumb architecture flags (-march=armv6s-m for instance) are also passed.
So my reading of the multilib Makefile fragment is that the "thumb" directory is what you get when you specify -mthumb with no CPU or architecture option, and if you say -mcpu=cortex-m0 -mthumb you will get the armv6-m multilib directory.
- The thumb version of libgcc.a is not built with thumb instructions because GCC doesn't pass -mthumb to the assembler when it receives -mthumb on the command line.
I would be expecting the compiler to pass .thumb in the assembler source to as.
- That's ok, because the GNU assembler doesn't listen to -mthumb anyways; I had to force the assembler to compile thumb instructions by passing it -mcpu=cortex-m0 on the command line to GCC, which is then passed along to the assembler.
Figured you'd like to know what progress I've made, at this point it looks like simple driver bugs. Once resolved, it looks like I'll be able to generate a debian package from the debian GCC sources and a small patch.
I hope this helps.
Thanks,
Matt
On 7 October 2013 11:30, Matthew Gretton-Dann matthew.gretton-dann@linaro.org wrote:
On 7 October 2013 05:20, Keith Packard keithp@keithp.com wrote:
[...]
- The thumb version of libgcc.a is not built with thumb instructions because GCC doesn't pass -mthumb to the assembler when it receives -mthumb on the command line.
I would be expecting the compiler to pass .thumb in the assembler source to as.
My experience with arm/thumb assembler are similar. With my Ubuntu stock 4.8 configured as
Using built-in specs. COLLECT_GCC=arm-linux-gnueabihf-gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc-cross/arm-linux-gnueabihf/4.8/lto-wrapper Target: arm-linux-gnueabihf Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.8.1-7ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.8 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/arm-linux-gnueabihf/include/c++/4.8.1 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libitm --disable-libquadmath --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-armhf-cross/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-armhf-cross --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-armhf-cross --with-arch-directory=arm --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libgcj --enable-objc-gc --enable-multiarch --enable-multilib --disable-sjlj-exceptions --with-arch=armv7-a --with-fpu=vfpv3-d16 --with-float=hard --with-mode=thumb --disable-werror --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=arm-linux-gnueabihf --program-prefix=arm-linux-gnueabihf- --includedir=/usr/arm-linux-gnueabihf/include Thread model: posix gcc version 4.8.1 (Ubuntu/Linaro 4.8.1-7ubuntu1)
I get the following unexpected results:
$ arm-linux-gnueabihf-gcc -mthumb -c -o /dev/null -xassembler - <<<"adrl r0,." $ arm-linux-gnueabihf-gcc -mthumb -c -o /dev/null -xassembler - <<<".thumb; adrl r0,." {standard input}: Assembler messages: {standard input}:1: Error: selected processor does not support Thumb mode `adrl r0,.'
i.e., the former passes while I would expect the assembler to be kicked into thumb mode by the compiler.
Matthew Gretton-Dann matthew.gretton-dann@linaro.org writes:
Can you please provide the output of:
- arm-none-eabi-gcc -v
- arm-none-eabi-gcc -print-multi-lib
Yeah, I figured it out, thanks -- the patches I had to add ARM multilib support updated configure.ac but I didn't rebuild the configure script, so my attempts to set the multilib values failed. It's working this morning and I've built one program with the resulting toolchain that worked correctly.
Thanks for your help!
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
+++ Matthew Gretton-Dann [2013-08-19 16:58 +0100]:
On 19 August 2013 15:04, Wookey wookey@wookware.org wrote:
Debconf13 (last week) considered the matter of bare-metal cross-toolchains in Debian.
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.
Aha. I had assumed it was something linaro was now doing. I'll see if I can find some more details inside ARM then.
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.
You misread (or I was unclear). The arm-provided toolchain referenced above does indeed work for M3 and M0. It's a toolchain built from debian sources that doesn't work for M0. Keithp did the tests and has the details of exactly what he tested. (are we talking 4.7 or 4.8 (or both) here keith?)
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.
OK, that will be useful but another big code dump with a huge diff is only a partial solution. We really want to get to see which important bits are actually missing in Debian.
The Linaro branch for 4.8 is in the main SVN repository for GCC: svn://gcc.gnu.org/branches/linaro/gcc-4_8-branch
OK. And do you think that should support M0 and M3 correctly already? Do we expect M0/M3 support there to be good? Or should I ask Joey these questions?
Debian is currently using 4.8.1 (with a pile of packaging patches and some backported fixes). So I guess the question really is whether that is expected to work.
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.
OK, that's helpful.
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.
Right.
Wookey
-----Original Message----- From: Wookey [mailto:wookey@wookware.org] Sent: Tuesday, August 20, 2013 0:31 To: linaro-dev@lists.linaro.org; Embedded Debian Cc: Joey Ye Subject: Re: M0 and M3 patches in linaro toolchains
+++ Matthew Gretton-Dann [2013-08-19 16:58 +0100]:
On 19 August 2013 15:04, Wookey wookey@wookware.org wrote:
Debconf13 (last week) considered the matter of bare-metal cross-toolchains in Debian.
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.
Aha. I had assumed it was something linaro was now doing. I'll see if I can find some more details inside ARM then.
It is still a fully open source project though. svn://gcc.gnu.org/branches/arm/embedded-4_8-branch/gcc/ChangeLog.arm listed everything diff to FSF 4.8 branch.
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.
You misread (or I was unclear). The arm-provided toolchain referenced above does indeed work for M3 and M0. It's a toolchain built from debian sources that doesn't work for M0. Keithp did the tests and has the details of exactly what he tested. (are we talking 4.7 or 4.8 (or both) here keith?)
I'm not sure what blocked M0. There are a few things suspicious: * Which C library is used? The one gcc-arm-embedded works, and the only one I know works for Cortex-M, is newlib. Other than that, good luck :-( * What is the newlib version, if you are using newlib. There were some patches for M0 when we enabled gcc-arm-embedded. But all of them are in latest newlib mainline now.
Overall, sharing a source between arm-linux and arm-none-eabi sounds a good idea, but library can be the road blocker. As bare-metal version should use newlib and linux use glibc, it is not that straight-forward as assumed. Please be aware of this extra burden.
Alternative approach is just grab the gcc-arm-embedded 4.8, which will be ready by Q4, and build it for debian. It will be straight forward as it is already built and released by launchpad as debian package and distributed as PPA. Also it will behavior the same as any other gcc-arm-embedded running on other linux distribution and Windows, which have been downloaded 100,000 copies.
I'm OK with both approaches but I believe the latter makes more sense.
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.
Yes, 4.8 will be release in Q4 this year. The arm/embedded-4_8-branch is now under development and will be the release branch by then.
OK, that will be useful but another big code dump with a huge diff is only a partial solution. We really want to get to see which important bits are actually missing in Debian.
As I mentioned in another email, everything is at svn://gcc.gnu.org/branches/arm/embedded-4_x-branch/gcc/ChangeLog.arm given that you got correct newlib. Major stuff to make it work is multilib support, which is a piece of Makefile fragment to build library for armv6-m/7-m/7-a/7-r.
The Linaro branch for 4.8 is in the main SVN repository for GCC: svn://gcc.gnu.org/branches/linaro/gcc-4_8-branch
OK. And do you think that should support M0 and M3 correctly already? Do we expect M0/M3 support there to be good? Or should I ask Joey these questions?
Again, I'm not sure what blocked M0. I'm interested to know more details about this.
Debian is currently using 4.8.1 (with a pile of packaging patches and some backported fixes). So I guess the question really is whether that is expected to work.
Should work with multilib Makefile fragment and correct newlib version
Regards, Joey
-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782
Wookey wookey@wookware.org writes:
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.
I've finished packaging binutils-arm-none-eabi, gcc-arm-none-eabi and pdclib-arm-none-eabi at this point and I think they're ready to upload to the archive.
Package: binutils-arm-none-eabi Version: 2.23.52.20130727-1+1
This is built from the binutils-source package without any additional patches by setting the target to arm-none-eabi.
The +1 in the version is the packaging version for the arm-none-eabi packaging bits, the rest is the source package version of binutils that it was compiled from.
git://git.debian.org/users/keithp/binutils-arm-none-eabi
Package: gcc-arm-none-eabi Version: 4.8.1-10+2
Built from the gcc-4.8-source package with the patch supplied by Matthias Klose applied along with some minor build fixes.
git://git.debian.org/users/keithp/gcc-arm-none-eabi
Package: pdclib-arm-none-eabi Version: 0.5-1
This comes from version 0.5 of pdclib, but I've hacked at it to integrate with the above gcc version better.
git://git.debian.org/users/keithp/pdclib-arm-none-eabi
GCC is completely stand-alone, and does not require pdclib at all to be useful. pdclib is just what I'm using.
All of these are available in a repository on my home machine:
deb http://keithp.com/archive/ unstable/ deb-src http://keithp.com/archive/ unstable/
-keith
-
Ard Biesheuvel -
Joey Ye -
Keith Packard -
Matthew Gretton-Dann -
Matthias Klose -
Wookey