It would be nice to have support for multiple ARM baremetal targets within a single crossdev toolchain, like package from https://launchpad.net/gcc-arm-embedded is doing. Apparently this is achieved by gcc-arm-embedded package by providing `--with-multilib-list=armv6-m,armv7-m,armv7e-m,armv7-r' argument to GCC's configure.
Created attachment 392314 [details, diff] toolchain-eclass.patch Initial step to get multiple arm uC architectures in. FPU handling stuff is still wrong: crossdev toolchain: $ arm-none-eabi-gcc-4.8.3 --print-multi-lib .; thumb;@mthumb fpu;@mfloat-abi=hard gcc-arm-embedded toolchain: $ arm-none-eabi-gcc-4.8.4 --print-multi-lib .; thumb;@mthumb fpu;@mfloat-abi=hard armv6-m;@mthumb@march=armv6s-m armv7-m;@mthumb@march=armv7-m armv7e-m;@mthumb@march=armv7e-m armv7-ar/thumb;@mthumb@march=armv7 armv7e-m/softfp;@mthumb@march=armv7e-m@mfloat-abi=softfp@mfpu=fpv4-sp-d16 armv7e-m/fpu;@mthumb@march=armv7e-m@mfloat-abi=hard@mfpu=fpv4-sp-d16 armv7-ar/thumb/softfp;@mthumb@march=armv7@mfloat-abi=softfp@mfpu=vfpv3-d16 armv7-ar/thumb/fpu;@mthumb@march=armv7@mfloat-abi=hard@mfpu=vfpv3-d16
See https://gcc.gnu.org/ml/gcc-patches/2012-05/msg00083.html This seem like a necessary patch for this feature. It's old, but I can't find any trace of it being merged into mainline gcc. At least it is not included in 4.8.3.
(In reply to Joakim Gebart from comment #2) > See https://gcc.gnu.org/ml/gcc-patches/2012-05/msg00083.html > > This seem like a necessary patch for this feature. It's old, but I can't > find any trace of it being merged into mainline gcc. At least it is not > included in 4.8.3. Cool, thanks for digging this up. Indeed, this isn't supported on vanilla gcc. After some digging I found the patch (probably) used for gcc-arm-embedded: https://gcc.gnu.org/ml/gcc-patches/2014-05/msg00729.html
It is possible to extract the patches used for building the current .deb package from the launchpad site: https://launchpad.net/~terry.guo/+archive/ubuntu/gcc-arm-embedded/+packages I have not found how to find a specific (older) version as I am not very familiar with launchpad. I would like to find the patchset used for 4.8.4 (before they switched to 4.9.2) since that is still the compiler I use on a daily basis. This is a build log of a 4.8.4 build: https://launchpad.net/~terry.guo/+archive/ubuntu/gcc-arm-embedded/+build/6449486 Any clues?
Unfortunately it's not that easy to fetch the patches themselves, but the sources live in the following svn branches: https://gcc.gnu.org/svn/gcc/branches/ARM/ The build itself seems to be fairly easy: Just download the big package: https://launchpad.net/gcc-arm-embedded/4.9/4.9-2015-q2-update/+download/gcc-arm-none-eabi-4_9-2015q2-20150609-src.tar.bz2 Which contains already patched source tarballs for all the required parts. Here's the excerpt from release.txt: [snip] * gcc : ARM/embedded-4_9-branch revision 224288 http://gcc.gnu.org/svn/gcc/branches/ARM/embedded-4_9-branch/ * binutils : 2.24 with mainline backports git://sourceware.org/git/binutils-gdb.git commit 136a940ac535e464d2a7a86880ce1f1a5554c484 * newlib and newlib-nano : git://sourceware.org/git/newlib-cygwin.git commit 3c932910e6a36bd70a16f70436f08945fbc833f3 * gdb : 7.8 with mainline backport/without target sim support git://sourceware.org/git/binutils-gdb.git commit c9792faa1e25cb54edf55ffce93582370c99e4ac * cloog 0.18.0 : ftp://gcc.gnu.org/pub/gcc/infrastructure/cloog-0.18.0.tar.gz * expat 2.0.1 : http://jaist.dl.sourceforge.net/project/expat/expat/2.0.1/expat-2.0.1.tar.gz * gmp 4.3.2 : ftp://gcc.gnu.org/pub/gcc/infrastructure/gmp-4.3.2.tar.bz2 * libelf 0.8.13 : http://www.mr511.de/software/libelf-0.8.13.tar.gz * libiconv 1.14 : http://ftp.gnu.org/gnu/libiconv/libiconv-1.14.tar.gz * mpc 0.8.1 : ftp://gcc.gnu.org/pub/gcc/infrastructure/mpc-0.8.1.tar.gz * mpfr 2.4.2 : ftp://gcc.gnu.org/pub/gcc/infrastructure/mpfr-2.4.2.tar.bz2 * isl 0.11.1 : ftp://gcc.gnu.org/pub/gcc/infrastructure/isl-0.11.1.tar.bz2 * zlib 1.2.8 http://sourceforge.net/projects/libpng/files/zlib/1.2.8/zlib-1.2.8.tar.gz/download [/snip]
if upstream ever merges the patch we can maybe take a look, but certainly the toolchain eclass patch as-is is not viable