Re: M0 and M3 patches in linaro toolchains

Matthias Klose <doko-GeWIH/[email protected]> writes:

> Am 19.08.2013 17:27, schrieb Keith Packard:
>> Wookey <wookey-Xpnwy/[email protected]> 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

_______________________________________________
linaro-dev mailing list
[email protected]
http://lists.linaro.org/mailman/listinfo/linaro-dev

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)

iQIVAwUBUlI2gtsiGmkAAAARAQgSSw/9EI0n/eT46KV7Py7OcTlW433OewpqQ1E1
YXO/JgFZWP19IHhmGKNEdTGGtsLEnOZ0RT+J1MP3gu0tflxgsOfV0bhirj0ZNIhB
iadEp8eXIpdrBcJKCCcWW3+9DF3jyJDZHBEBzclB4+vuE+rirYcZFPaIQUgZTKEO
0zGmjxI1YKHZU3wvhbY8xUa7V/3q6RSpj+zw7vnrXfIzwjCiolzLdN/ufCg0+Jhz
UQ5SQUNf/ilPgIGYVqTsPT1+h+SSuX7FbbHc8dd6cdEP224Y8HTvuRObonjv0FlC
XWE7u+FMsTrhPesUEQm9btiZmHBimTAnl+YfPNdYyXSSZd9K4VnYJot8wFmdYzKU
m+JxKeegLcF2wiVtZJzD0TXUMaa3c5NdWjl5R0vkOWAI7WY0dl3ZRCjlT2xVHNaj
LMUXjgLggAIZfyvZnjRl2f/9Wqr/CLFIUJmUszUWYNUzkrybOHHmGnQs9IsqPVeV
J4Qt1Xw2N2njgpx9T16NwfBwwmulvi4+Lgyf5oSbqAFZBcCQ6rPDArbsXn8Bf332
mM3XzGy2nwsDy9zcufOGpx0ZZEuNHiYwq0Ec9SErTNU9xTqc79afzbshGxSOnTQC
th9pRr0zSxuiHm2SZ28rNGoNl6nH2n8llnLH0pGdXpqtPgnfgIAmXwCZeEbmKQen
6U+P2t7XeV4=
=k395
-----END PGP SIGNATURE-----