[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: M0 and M3 patches in linaro toolchains

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;",
   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


Attachment: pgpaSUHbGEpnt.pgp
Description: PGP signature

Reply to: