On Sunday, 26 April 2015 at 18:23:47 UTC, Martin Nowak wrote:

> The wiki says to disable multilib
> (http://wiki.dlang.org/Bare_Metal_ARM_Cortex-M_GDC_Cross_Compiler#Build_GCC),
> what's the problem? Maybe ask Iain/Johannes if it's GDC specific.

I have also tried for years to build a working multilib without success. Now I think I have been able to get all versions to work. I welcome everyone to test and report if this works.

The build script:
../gcc/configure --disable-bootstrap \
--enable-languages=c,d  --disable-nls --target=arm-eabi \
--without-headers  --with-newlib --without-isl --without-cloog \
--disable-libphobos --disable-libstdcxx --disable-libbacktrace\
--enable-multilib

And I replace the whole gcc/config/arm/t-arm-elf with this:
MULTILIB_OPTIONS  += mcpu=cortex-m0/mcpu=cortex-m3/mcpu=cortex-m4  mfloat-abi=hard mfpu=fpv4-sp-d16
MULTILIB_DIRNAMES += cortex-m0 cortex-m3 cortex-m4
MULTILIB_REQUIRED += mcpu=cortex-m0
MULTILIB_REQUIRED += mcpu=cortex-m3
MULTILIB_REQUIRED += mcpu=cortex-m4 #/mfloat-abi=hard  #/mfpu=fpv4-sp-d16
MULTILIB_EXTRA_OPTS += mthumb


This will build m0 and m3 with soft float and m4 with hard float. I have used gdc head + gcc 6 head from about a week ago. It may be possible this will work with gcc 5.1 release + gdc 5  and I hope somebody will test this.

Please note: This is the first time ever I have suceeded. This will not work with any gcc before april. An older gcc will not build m4 or it may even not pass configuring.

So please test and report.

>
> What libc are you using? The gcc-arm-embedded project uses newlib and
> newlib-nano. https://launchpad.net/gcc-arm-embedded

I have used standard newlib from sources. There were some discussions that libc should not be needed any more to build the compiler. I can not test this because I do not have a totally clean environment right now. So if anybody could advice me or just test if it is currently possible to build without libc.

On Monday, 27 April 2015 at 05:19:52 UTC, Timo Sintonen wrote:

Oops, I forget to uncomment the m4 options. The correct version is
>
> And I replace the whole gcc/config/arm/t-arm-elf with this:
> MULTILIB_OPTIONS  += mcpu=cortex-m0/mcpu=cortex-m3/mcpu=cortex-m4
>  mfloat-abi=hard mfpu=fpv4-sp-d16
> MULTILIB_DIRNAMES += cortex-m0 cortex-m3 cortex-m4
> MULTILIB_REQUIRED += mcpu=cortex-m0
> MULTILIB_REQUIRED += mcpu=cortex-m3
> MULTILIB_REQUIRED += mcpu=cortex-m4 /mfloat-abi=hard  /mfpu=fpv4-sp-d16
> MULTILIB_EXTRA_OPTS += mthumb
>
>

On Sunday, 26 April 2015 at 16:09:57 UTC, Martin Nowak wrote:

> Nice, minilibd seems to be maintained as well, you happen to know the
> author?

I am the author of minlibd

> I'd really like to see binary releases of GDC for arm-none-eabi that
> ship with a patched compiler (iff necessary) and minilibd.

One of the biggest issues has been the multilib build. If it is solved now we are one step closer to be able to build binaries.

On 26 April 2015 at 22:41, Jens Bauer via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Sunday, 26 April 2015 at 18:23:47 UTC, Martin Nowak wrote:
>>
>> On 04/26/2015 07:29 PM, Jens Bauer wrote:
>>>
>>> Unfortunately, I have not been able to build with multilib yet, so my setup cannot build code for Cortex-M0; it keeps stuffing Cortex-M3 and Cortex-M4 instructions in there.
>>
>>
>> The wiki says to disable multilib
>>
>> (http://wiki.dlang.org/Bare_Metal_ARM_Cortex-M_GDC_Cross_Compiler#Build_GCC),
>> what's the problem?
>
>
> The problem is that I cannot have a single compiler, which compiles for
> these architectures:
> ARM7TDMI
> Cortex-M0
> Cortex-M3
> Cortex-M4
>
> Using a Cortex-M3 or Cortex-M4 compiler to build code for a Cortex-M0, will insert 32-bit instructions randomly (most code is 16-bit, though, so parts of it gets it right). As soon as the microcontroller tries to run a 32-bit instruction, it will crash.
>
> -In order to build code for Cortex-M0 or Cortex-M0+, I will have to rebuild
> the compiler.
> The alternative is to build 5 different compilers. I don't want that either.
>
> ...
>
> The reason I cannot build GDC with multilib, is that I get a compile-error
> when building the final GCC+GDC.
> Building GCC alone without GDC gives me no such error.
> -So if I want to have multilib support, I will have to be without GDC.

Where exactly does it error?

I can't think of a sole reason why gdc/libphobos would throw an error in multilib builds, so it must be something collateral (libstdc++) ?

Regards
Iain.

On 27 April 2015 at 07:22, Timo Sintonen via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Monday, 27 April 2015 at 05:19:52 UTC, Timo Sintonen wrote:
>
> Oops, I forget to uncomment the m4 options. The correct version is
>>
>>
>> And I replace the whole gcc/config/arm/t-arm-elf with this:
>> MULTILIB_OPTIONS  += mcpu=cortex-m0/mcpu=cortex-m3/mcpu=cortex-m4
>>  mfloat-abi=hard mfpu=fpv4-sp-d16
>> MULTILIB_DIRNAMES += cortex-m0 cortex-m3 cortex-m4
>> MULTILIB_REQUIRED += mcpu=cortex-m0
>> MULTILIB_REQUIRED += mcpu=cortex-m3
>> MULTILIB_REQUIRED += mcpu=cortex-m4 /mfloat-abi=hard  /mfpu=fpv4-sp-d16
>> MULTILIB_EXTRA_OPTS += mthumb
>>
>>
>

Maybe you could instead create a new file under config/arm/t-mprofile, for use with --with-multilib-list=mprofile  (see patch below).

See config/arm/t-aprofile for guidance, which looks to be tailored multilib support for the Cortex-A range of CPUs.

I can ask around if someone has done something similar for Cortex-M.

Regards
Iain.

--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -3711,6 +3711,28 @@ case "${target}" in
                                        tmake_file="${tmake_file}
arm/t-aprofile"
                                        break
                                        ;;
+                               mprofile)
+                               # Note that arm/t-mprofile is a
+                               # stand-alone make file fragment to be
+                               # used only with itself.  We do not
+                               # specifically use the
+                               # TM_MULTILIB_OPTION framework because
+                               # this shorthand is more
+                               # pragmatic. Additionally it is only
+                               # designed to work without any
+                               # with-cpu, with-arch with-mode
+                               # with-fpu or with-float options.
+                                       if test "x$with_arch" != x \
+                                           || test "x$with_cpu" != x \
+                                           || test "x$with_float" != x \
+                                           || test "x$with_fpu" != x \
+                                           || test "x$with_mode" != x ; then
+                                           echo "Error: You cannot
use any of --with-arch/cpu/fpu/float/mode with
--with-multilib-list=mprofile" 1>&2
+                                           exit 1
+                                       fi
+                                       tmake_file="${tmake_file}
arm/t-mprofile"
+                                       break
+                                       ;;
                                default)
                                        ;;
                                *)

On 27 April 2015 at 08:28, Iain Buclaw <ibuclaw@gdcproject.org> wrote:
> On 27 April 2015 at 07:22, Timo Sintonen via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>> On Monday, 27 April 2015 at 05:19:52 UTC, Timo Sintonen wrote:
>>
>> Oops, I forget to uncomment the m4 options. The correct version is
>>>
>>>
>>> And I replace the whole gcc/config/arm/t-arm-elf with this:
>>> MULTILIB_OPTIONS  += mcpu=cortex-m0/mcpu=cortex-m3/mcpu=cortex-m4
>>>  mfloat-abi=hard mfpu=fpv4-sp-d16
>>> MULTILIB_DIRNAMES += cortex-m0 cortex-m3 cortex-m4
>>> MULTILIB_REQUIRED += mcpu=cortex-m0
>>> MULTILIB_REQUIRED += mcpu=cortex-m3
>>> MULTILIB_REQUIRED += mcpu=cortex-m4 /mfloat-abi=hard  /mfpu=fpv4-sp-d16
>>> MULTILIB_EXTRA_OPTS += mthumb
>>>
>>>
>>
>
> Maybe you could instead create a new file under config/arm/t-mprofile, for use with --with-multilib-list=mprofile  (see patch below).
>
> See config/arm/t-aprofile for guidance, which looks to be tailored multilib support for the Cortex-A range of CPUs.
>

Also stumbled across: https://github.com/prattmic/arm-cortex-m4-hardfloat-toolchain/blob/master/patches/gcc-multilib.patch

On Monday, 27 April 2015 at 05:22:55 UTC, Timo Sintonen wrote:
> On Monday, 27 April 2015 at 05:19:52 UTC, Timo Sintonen wrote:
>
> Oops, I forget to uncomment the m4 options. The correct version is
>>
>> And I replace the whole gcc/config/arm/t-arm-elf with this:
>> MULTILIB_OPTIONS  += mcpu=cortex-m0/mcpu=cortex-m3/mcpu=cortex-m4
>> mfloat-abi=hard mfpu=fpv4-sp-d16
>> MULTILIB_DIRNAMES += cortex-m0 cortex-m3 cortex-m4
>> MULTILIB_REQUIRED += mcpu=cortex-m0
>> MULTILIB_REQUIRED += mcpu=cortex-m3
>> MULTILIB_REQUIRED += mcpu=cortex-m4 /mfloat-abi=hard  /mfpu=fpv4-sp-d16
>> MULTILIB_EXTRA_OPTS += mthumb

The toolchain at https://launchpad.net/gcc-arm-embedded doesn't require this modification, so I'm wondering if there's another way.  My understanding is that this is unlreated to GDC itself, so we should be able to follow essentially the same procedure as the embedded C/C++ toolchains, right?

They have their build scripts included in their source package, so I spent a little time analyzing their build scripts today, and I see they are using the following config option:

"--with-multilib-list=armv6-m,armv7-m,armv7e-m,cortex-m7,armv7-r"

I'm wondering if that alone will do it.  I guess I'll give it a try later and let you all know what I find.

Mike

On 27 April 2015 at 09:34, Mike via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Monday, 27 April 2015 at 05:22:55 UTC, Timo Sintonen wrote:
>>
>> On Monday, 27 April 2015 at 05:19:52 UTC, Timo Sintonen wrote:
>>
>> Oops, I forget to uncomment the m4 options. The correct version is
>>>
>>>
>>> And I replace the whole gcc/config/arm/t-arm-elf with this:
>>> MULTILIB_OPTIONS  += mcpu=cortex-m0/mcpu=cortex-m3/mcpu=cortex-m4
>>> mfloat-abi=hard mfpu=fpv4-sp-d16
>>> MULTILIB_DIRNAMES += cortex-m0 cortex-m3 cortex-m4
>>> MULTILIB_REQUIRED += mcpu=cortex-m0
>>> MULTILIB_REQUIRED += mcpu=cortex-m3
>>> MULTILIB_REQUIRED += mcpu=cortex-m4 /mfloat-abi=hard  /mfpu=fpv4-sp-d16
>>> MULTILIB_EXTRA_OPTS += mthumb
>
>
> The toolchain at https://launchpad.net/gcc-arm-embedded doesn't require this modification, so I'm wondering if there's another way.  My understanding is that this is unlreated to GDC itself, so we should be able to follow essentially the same procedure as the embedded C/C++ toolchains, right?
>
> They have their build scripts included in their source package, so I spent a little time analyzing their build scripts today, and I see they are using the following config option:
>
> "--with-multilib-list=armv6-m,armv7-m,armv7e-m,cortex-m7,armv7-r"
>
> I'm wondering if that alone will do it.  I guess I'll give it a try later and let you all know what I find.
>

>From what I'm reading in config.gcc, ARM does not support
--with-multilib-list= *except* for 'default' and 'aprofile'.  So Ubuntu/Canonical must be applying local patches to get that working.

Iain.

On Monday, 27 April 2015 at 05:30:55 UTC, Timo Sintonen wrote:
> One of the biggest issues has been the multilib build. If it is solved now we are one step closer to be able to build binaries.

Great, I tried to find out how GDC binaries are build, but couldn't find any script.

How much stuff do you strip out of runtime for minilibd? It still seems to contain fat typeinfo and moduleinfo. We'd probably need the equivalent of -no-rtti and -fno-exceptions and add -fno-moduleinfo.

Maybe building a few different configurations of minilibd makes sense.
The ARM toolchain comes with a nano.spec to select newlib-nano and size optimized libc++.
https://launchpadlibrarian.net/200699979/readme.txt

On 27 April 2015 at 09:47, Iain Buclaw <ibuclaw@gdcproject.org> wrote:
> On 27 April 2015 at 09:34, Mike via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>> On Monday, 27 April 2015 at 05:22:55 UTC, Timo Sintonen wrote:
>>>
>>> On Monday, 27 April 2015 at 05:19:52 UTC, Timo Sintonen wrote:
>>>
>>> Oops, I forget to uncomment the m4 options. The correct version is
>>>>
>>>>
>>>> And I replace the whole gcc/config/arm/t-arm-elf with this:
>>>> MULTILIB_OPTIONS  += mcpu=cortex-m0/mcpu=cortex-m3/mcpu=cortex-m4
>>>> mfloat-abi=hard mfpu=fpv4-sp-d16
>>>> MULTILIB_DIRNAMES += cortex-m0 cortex-m3 cortex-m4
>>>> MULTILIB_REQUIRED += mcpu=cortex-m0
>>>> MULTILIB_REQUIRED += mcpu=cortex-m3
>>>> MULTILIB_REQUIRED += mcpu=cortex-m4 /mfloat-abi=hard  /mfpu=fpv4-sp-d16
>>>> MULTILIB_EXTRA_OPTS += mthumb
>>
>>
>> The toolchain at https://launchpad.net/gcc-arm-embedded doesn't require this modification, so I'm wondering if there's another way.  My understanding is that this is unlreated to GDC itself, so we should be able to follow essentially the same procedure as the embedded C/C++ toolchains, right?
>>
>> They have their build scripts included in their source package, so I spent a little time analyzing their build scripts today, and I see they are using the following config option:
>>
>> "--with-multilib-list=armv6-m,armv7-m,armv7e-m,cortex-m7,armv7-r"
>>
>> I'm wondering if that alone will do it.  I guess I'll give it a try later and let you all know what I find.
>>
>
> From what I'm reading in config.gcc, ARM does not support --with-multilib-list= *except* for 'default' and 'aprofile'.  So Ubuntu/Canonical must be applying local patches to get that working.
>

Yep!  Here's the local patch:  http://pastebin.com/D3RmCNMf

Regards
Iain