On Fri, 2017-08-18 at 11:17 -0500, R0b0t1 wrote: > Just to check, this is actually an > arm-none-eabi toolchain? I looked over the compilation flags and it > looks like it supports all Cortex-M processor features like such a > toolchain should. Most instructions I could find seemed to build a > more restricted toolchain.
The toolchain you get from this script supports - in case of GCC 7 - following multilibs: -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- $ arm-none-eabi-gcc -print-multi-lib .; thumb;@mthumb hard;@mfloat-abi=hard thumb/v6-m;@mthumb@march=armv6s-m thumb/v7-m;@mthumb@march=armv7-m thumb/v7e-m;@mthumb@march=armv7e-m thumb/v7-ar;@mthumb@march=armv7 thumb/v8-m.base;@mthumb@march=armv8-m.base thumb/v8-m.main;@mthumb@march=armv8-m.main thumb/v7e-m/fpv4-sp/softfp;@mthumb@march=armv7e-m@mfpu=fpv4-sp-d16@mfloat-abi=softfp thumb/v7e-m/fpv4-sp/hard;@mthumb@march=armv7e-m@mfpu=fpv4-sp-d16@mfloat-abi=hard thumb/v7e-m/fpv5-sp/softfp;@mthumb@march=armv7e-m@mfpu=fpv5-sp-d16@mfloat-abi=softfp thumb/v7e-m/fpv5-sp/hard;@mthumb@march=armv7e-m@mfpu=fpv5-sp-d16@mfloat-abi=hard thumb/v7e-m/fpv5/softfp;@mthumb@march=armv7e-m@mfpu=fpv5-d16@mfloat-abi=softfp thumb/v7e-m/fpv5/hard;@mthumb@march=armv7e-m@mfpu=fpv5-d16@mfloat-abi=hard thumb/v7-ar/fpv3/softfp;@mthumb@march=armv7@mfpu=vfpv3-d16@mfloat-abi=softfp thumb/v7-ar/fpv3/hard;@mthumb@march=armv7@mfpu=vfpv3-d16@mfloat-abi=hard thumb/v8-m.main/fpv5-sp/softfp;@mthumb@march=armv8-m.main@mfpu=fpv5-sp-d16@mfloat-abi=softfp thumb/v8-m.main/fpv5-sp/hard;@mthumb@march=armv8-m.main@mfpu=fpv5-sp-d16@mfloat-abi=hard thumb/v8-m.main/fpv5/softfp;@mthumb@march=armv8-m.main@mfpu=fpv5-d16@mfloat-abi=softfp thumb/v8-m.main/fpv5/hard;@mthumb@march=armv8-m.main@mfpu=fpv5-d16@mfloat-abi=hard -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- That means you can use all ARM Cortex-M chips, with or without FPU, 32- bit or 64-bit. You can also use ARM Cortex-R and "classic" ARM7TDMI. This is the same set of architectures you get from the toolchain provided by ARM. > I have looked at the supporting blog posts and read the documentation > available. The blog post is really old and the part about performance is mostly obsolte (; > I still do not understand why the specific binutils, gcc, > newlib, and gdb configurations were chosen, and why what is > ostensibly > the same configuration failed when I tried it Would you please take > the time to document them, or point me towards a place that describes > what I should be looking for and why? I don't mind reading but I do > not know why the choices made are the correct ones and have been > unable to find anywhere that starts to offer any explanation. Generally I used the most recent components which are available for download. In the past - up to and including GCC 6 - the only exception were the cases of supporting libraries (stuff like isl, mpfr, ...), where _sometimes_ gcc docs say you must use a release from range x-y, not the most recent one. In that case the most recent package from the range is chosen. However the file gcc-7.2.0/gcc/doc/install.texi always says "version x (or later)" so... I use the most recent one (; After all, this is a "bleeding-edge" toolchain (; Sometimes the version may be a bit older than the most recent one either because I forgot to check, or because the most recent one has some problems. This is the case for the most recent newlib snapshot which fails to build for ARM - that's why I had to use a previous one. Regards, FCh
