Thread overview | |||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
May 19, 2019 GDC 9 and ARM Cortex-M | ||||
---|---|---|---|---|
| ||||
I am updating my toolset and libraries to GCC/GDC 9.1 release. First impression is that druntime needs more work than with previous versions. Many places to change and even compiler crashes when compiling some files. Before I look further I want to ask if there has been any testing with this target (cross compiler linux->arm-eabi). Is it expected to work, not to work or not tested at all. |
May 19, 2019 Re: GDC 9 and ARM Cortex-M | ||||
---|---|---|---|---|
| ||||
Posted in reply to Timo Sintonen | Am Sun, 19 May 2019 06:54:14 +0000 schrieb Timo Sintonen: > I am updating my toolset and libraries to GCC/GDC 9.1 release. First impression is that druntime needs more work than with previous versions. Many places to change and even compiler crashes when compiling some files. > > Before I look further I want to ask if there has been any testing with this target (cross compiler linux->arm-eabi). Is it expected to work, not to work or not tested at all. Cross-compilers in general are expected to work, but only basic testing has been done. Bare-metal targets have some basic betterC testing, but we only test without druntime. We never tested druntime or stripped-down druntime on baremetal targets. Compiler crashes are certainly bugs and should be reported. Druntime requiring more changes now is sad, but not really unexpected as I don't think anyone in the druntime team focuses on embedded targets. I guess most people working on bare-metal completely reimplement a custom runtime or use betterC with the C runtime only. -- Johannes |
May 19, 2019 Re: GDC 9 and ARM Cortex-M | ||||
---|---|---|---|---|
| ||||
Posted in reply to Timo Sintonen | On Sunday, 19 May 2019 at 06:54:14 UTC, Timo Sintonen wrote: > I am updating my toolset and libraries to GCC/GDC 9.1 release. First impression is that druntime needs more work than with previous versions. Many places to change and even compiler crashes when compiling some files. > > Before I look further I want to ask if there has been any testing with this target (cross compiler linux->arm-eabi). Is it expected to work, not to work or not tested at all. Several months ago, I used this script (https://github.com/JinShil/native-gdc/blob/master/native-gdc.sh) to build a native GDC compiler. I then used that compiler by way of this script (https://github.com/JinShil/arm-none-eabi-gdc/blob/master/arm-none-eabi-gdc.sh) to build an arm-none-eabi cross-compiler from head. I then used that cross-compiler to build this ARM Cortex-M project (https://github.com/JinShil/stm32f42_discovery_demo). Everything worked fine. I don't know if that helps, but that's my experience for whatever it's worth. Mike |
May 19, 2019 Re: GDC 9 and ARM Cortex-M | ||||
---|---|---|---|---|
| ||||
Posted in reply to Johannes Pfau | On Sunday, 19 May 2019 at 09:34:55 UTC, Johannes Pfau wrote:
> Am Sun, 19 May 2019 06:54:14 +0000 schrieb Timo Sintonen:
>
>> I am updating my toolset and libraries to GCC/GDC 9.1 release. First impression is that druntime needs more work than with previous versions. Many places to change and even compiler crashes when compiling some files.
>>
>> Before I look further I want to ask if there has been any testing with this target (cross compiler linux->arm-eabi). Is it expected to work, not to work or not tested at all.
>
> Cross-compilers in general are expected to work, but only basic testing
> has been done. Bare-metal targets have some basic betterC testing, but we
> only test without druntime. We never tested druntime or stripped-down
> druntime on baremetal targets. Compiler crashes are certainly bugs and
> should be reported.
> Druntime requiring more changes now is sad, but not really unexpected as
> I don't think anyone in the druntime team focuses on embedded targets. I
> guess most people working on bare-metal completely reimplement a custom
> runtime or use betterC with the C runtime only.
It looks like there is an ice with several files in rt/typeinfo.
I'll make a bug report when I know more.
|
May 19, 2019 Re: GDC 9 and ARM Cortex-M | ||||
---|---|---|---|---|
| ||||
Posted in reply to Mike Franklin | On Sunday, 19 May 2019 at 10:49:51 UTC, Mike Franklin wrote: > On Sunday, 19 May 2019 at 06:54:14 UTC, Timo Sintonen wrote: >> I am updating my toolset and libraries to GCC/GDC 9.1 release. First impression is that druntime needs more work than with previous versions. Many places to change and even compiler crashes when compiling some files. >> >> Before I look further I want to ask if there has been any testing with this target (cross compiler linux->arm-eabi). Is it expected to work, not to work or not tested at all. > > Several months ago, I used this script (https://github.com/JinShil/native-gdc/blob/master/native-gdc.sh) to build a native GDC compiler. I then used that compiler by way of this script (https://github.com/JinShil/arm-none-eabi-gdc/blob/master/arm-none-eabi-gdc.sh) to build an arm-none-eabi cross-compiler from head. > > I then used that cross-compiler to build this ARM Cortex-M project (https://github.com/JinShil/stm32f42_discovery_demo). Everything worked fine. > > I don't know if that helps, but that's my experience for whatever it's worth. > > Mike As we know there is always three possible sources of failure: - the compiler sources may have a bug - my local tools (gcc binutils etc) may build a buggy compiler - my use of the built compiler is wrong (compiler flags etc) This is what I currently use to build the compiler. C compilers built with this are used in production. cat >file <<EOF MULTILIB_OPTIONS += mcpu=cortex-m0/mcpu=cortex-m0plus/mcpu=cortex-m3/mcpu=cortex-m4/mcpu=cortex-m7 mfloat-abi=hard mfpu=fpv4-sp-d16 mfpu=fpv5-sp-d16 MULTILIB_DIRNAMES += cortex-m0 cortex-m0plus cortex-m3 cortex-m4 cortex-m7 hardfp fpv4 fpv5 MULTILIB_REQUIRED += mcpu=cortex-m0 MULTILIB_REQUIRED += mcpu=cortex-m0plus MULTILIB_REQUIRED += mcpu=cortex-m3 MULTILIB_REQUIRED += mcpu=cortex-m4/mfloat-abi=hard/mfpu=fpv4-sp-d16 MULTILIB_REQUIRED += mcpu=cortex-m7/mfloat-abi=hard/mfpu=fpv5-sp-d16 MULTILIB_EXTRA_OPTS += mthumb EOF cp file gcc/gcc/config/arm/t-arm-elf rm -rf build-gcc mkdir build-gcc cd build-gcc ../gcc/configure --disable-bootstrap --disable-nls --disable-werror \ --target=arm-eabi --enable-languages=c,d \ --without-isl --without-cloog \ --enable-multilib --disable-libphobos \ --disable-libstdcxx --disable-libssp --disable-libquadmath \ --without-headers --with-newlib --with-system-zlib |
May 19, 2019 Re: GDC 9 and ARM Cortex-M | ||||
---|---|---|---|---|
| ||||
Posted in reply to Timo Sintonen | On Sun, 19 May 2019 at 16:00, Timo Sintonen via D.gnu <d.gnu@puremagic.com> wrote: > > On Sunday, 19 May 2019 at 10:49:51 UTC, Mike Franklin wrote: > > On Sunday, 19 May 2019 at 06:54:14 UTC, Timo Sintonen wrote: > >> I am updating my toolset and libraries to GCC/GDC 9.1 release. First impression is that druntime needs more work than with previous versions. Many places to change and even compiler crashes when compiling some files. > >> > >> Before I look further I want to ask if there has been any testing with this target (cross compiler linux->arm-eabi). Is it expected to work, not to work or not tested at all. > > > > Several months ago, I used this script > > (https://github.com/JinShil/native-gdc/blob/master/native-gdc.sh) to build a native GDC compiler. I then used that compiler by way of this script (https://github.com/JinShil/arm-none-eabi-gdc/blob/master/arm-none-eabi-gdc.sh) to build an arm-none-eabi cross-compiler from head. > > > > I then used that cross-compiler to build this ARM Cortex-M project (https://github.com/JinShil/stm32f42_discovery_demo). Everything worked fine. > > > > I don't know if that helps, but that's my experience for whatever it's worth. > > > > Mike > > As we know there is always three possible sources of failure: > - the compiler sources may have a bug > - my local tools (gcc binutils etc) may build a buggy compiler > - my use of the built compiler is wrong (compiler flags etc) > > This is what I currently use to build the compiler. C compilers built with this are used in production. > > cat >file <<EOF > MULTILIB_OPTIONS += > mcpu=cortex-m0/mcpu=cortex-m0plus/mcpu=cortex-m3/mcpu=cortex-m4/mcpu=cortex-m7 mfloat-abi=hard mfpu=fpv4-sp-d16 mfpu=fpv5-sp-d16 > MULTILIB_DIRNAMES += cortex-m0 cortex-m0plus cortex-m3 cortex-m4 > cortex-m7 hardfp fpv4 fpv5 > MULTILIB_REQUIRED += mcpu=cortex-m0 > MULTILIB_REQUIRED += mcpu=cortex-m0plus > MULTILIB_REQUIRED += mcpu=cortex-m3 > MULTILIB_REQUIRED += > mcpu=cortex-m4/mfloat-abi=hard/mfpu=fpv4-sp-d16 > MULTILIB_REQUIRED += > mcpu=cortex-m7/mfloat-abi=hard/mfpu=fpv5-sp-d16 > MULTILIB_EXTRA_OPTS += mthumb > > EOF > cp file gcc/gcc/config/arm/t-arm-elf > > rm -rf build-gcc > mkdir build-gcc > cd build-gcc > > ../gcc/configure --disable-bootstrap --disable-nls > --disable-werror \ > --target=arm-eabi --enable-languages=c,d \ > --without-isl --without-cloog \ > --enable-multilib --disable-libphobos \ > --disable-libstdcxx --disable-libssp --disable-libquadmath \ > --without-headers --with-newlib --with-system-zlib > You could also use the new binaries I uploaded to compiler explorer for cross-checking whether the ICE is independently reproducible. https://explore.dgnu.org/z/WKKMCg I don't really expect any part of druntime to build on bare metal. Too much depends on libc being available. -- Iain |
May 19, 2019 Re: GDC 9 and ARM Cortex-M | ||||
---|---|---|---|---|
| ||||
Posted in reply to Iain Buclaw | On Sunday, 19 May 2019 at 14:17:05 UTC, Iain Buclaw wrote: > > I don't really expect any part of druntime to build on bare metal. Too much depends on libc being available. I have done this several times so I mostly know what I am doing and I do understand that this may also be something in my local setup. > You could also use the new binaries I uploaded to compiler explorer for cross-checking whether the ICE is independently reproducible. > > https://explore.dgnu.org/z/WKKMCg > Cannot reproduce there. If you do not mind I include the long version here. There is a failure in about 10 files and the others pass. It seems it is the first function in the file. I do not know if it is just because it is the first or is there something inside that function. (btw why the gdc title is printed twice) arm-eabi-gdc -Wall -Wfatal-errors -O2 -frelease -fversion=NoSystem -fno-bounds-check -Wa,-ahls=rt/typeinfo/ti_Aint.o.l --verbose -fno-moduleinfo -fversion=GNU_ARM_EABI_Unwinder -fversion=STM32F4 -mcpu=cortex-m4 -mthumb -mfpu=fpv4-sp-d16 -mfloat-abi=hard -c rt/typeinfo/ti_Aint.d -o rt/typeinfo/ti_Aint.o Using built-in specs. COLLECT_GCC=arm-eabi-gdc Target: arm-eabi Configured with: ../gcc/configure --disable-bootstrap --disable-nls --disable-werror --target=arm-eabi --enable-languages=c,d --without-isl --without-cloog --enable-multilib --disable-libphobos --disable-libstdcxx --disable-libssp --disable-libquadmath --without-headers --with-newlib --with-system-zlib Thread model: single gcc version 9.1.0 (GCC) COLLECT_GCC_OPTIONS='-Wall' '-Wfatal-errors' '-O2' '-frelease' '-fversion=NoSystem' '-fno-bounds-check' '-v' '-fno-moduleinfo' '-fversion=GNU_ARM_EABI_Unwinder' '-fversion=STM32F4' '-mcpu=cortex-m4' '-mthumb' '-mfpu=fpv4-sp-d16' '-mfloat-abi=hard' '-c' '-o' 'rt/typeinfo/ti_Aint.o' '-march=armv7e-m+fp' /usr/local/libexec/gcc/arm-eabi/9.1.0/d21 rt/typeinfo/ti_Aint.d -quiet -dumpbase ti_Aint.d -mcpu=cortex-m4 -mthumb -mfpu=fpv4-sp-d16 -mfloat-abi=hard -march=armv7e-m+fp -auxbase-strip rt/typeinfo/ti_Aint.o -O2 -Wall -Wfatal-errors -version -frelease -fversion=NoSystem -fno-bounds-check -fno-moduleinfo -fversion=GNU_ARM_EABI_Unwinder -fversion=STM32F4 -imultilib cortex-m4/hardfp/fpv4 -v -o /tmp/ccuXKTnJ.s GNU D (GCC) version 9.1.0 (arm-eabi) compiled by GNU C version 8.2.0, GMP version 6.1.2, MPFR version 4.0.1, MPC version 1.1.0, isl version none GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU D (GCC) version 9.1.0 (arm-eabi) compiled by GNU C version 8.2.0, GMP version 6.1.2, MPFR version 4.0.1, MPC version 1.1.0, isl version none GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 binary /usr/local/libexec/gcc/arm-eabi/9.1.0/d21 version v2.076.1 predefs NoSystem GNU_ARM_EABI_Unwinder STM32F4 GNU D_Version2 LittleEndian GNU_StackGrowsDown GNU_InlineAsm D_NoBoundsChecks D_ModuleInfo D_Exceptions D_TypeInfo all ARM Thumb ARM_Thumb ARM_HardFloat D_HardFloat CppRuntime_Gcc parse ti_Aint importall ti_Aint import object (object.d) import core.internal.hash (core/internal/hash.d) import core.internal.traits (core/internal/traits.d) import core.internal.convert (core/internal/convert.d) import core.stdc.string (core/stdc/string.d) semantic ti_Aint semantic2 ti_Aint semantic3 ti_Aint d21: internal compiler error: Segmentation fault 0xb1b98f crash_signal ../../gcc/gcc/toplev.c:326 0x65327d Module::isRoot() ../../gcc/gcc/d/dmd/module.h:143 0x65327d TemplateInstance::appendToModuleMember() ../../gcc/gcc/d/dmd/dtemplate.c:7444 0x656e92 TemplateInstance::semantic(Scope*, Array<Expression*>*) ../../gcc/gcc/d/dmd/dtemplate.c:6123 0x657b74 functionResolve(Match*, Dsymbol*, Loc, Scope*, Array<RootObject*>*, Type*, Array<Expression*>*) ../../gcc/gcc/d/dmd/dtemplate.c:2582 0x68e3af resolveFuncCall(Loc, Scope*, Dsymbol*, Array<RootObject*>*, Type*, Array<Expression*>*, int) ../../gcc/gcc/d/dmd/func.c:3485 0x684622 ExpressionSemanticVisitor::visit(CallExp*) ../../gcc/gcc/d/dmd/expressionsem.c:3330 0x673425 semantic(Expression*, Scope*) ../../gcc/gcc/d/dmd/expressionsem.c:8158 0x6f30d0 StatementSemanticVisitor::visit(ReturnStatement*) ../../gcc/gcc/d/dmd/statementsem.c:2489 0x6f179a semantic(Statement*, Scope*) ../../gcc/gcc/d/dmd/statementsem.c:3498 0x6f179a StatementSemanticVisitor::visit(CompoundStatement*) ../../gcc/gcc/d/dmd/statementsem.c:139 0x6edbd5 semantic(Statement*, Scope*) ../../gcc/gcc/d/dmd/statementsem.c:3498 0x694bde FuncDeclaration::semantic3(Scope*) ../../gcc/gcc/d/dmd/func.c:1696 0x64406f AggregateDeclaration::semantic3(Scope*) ../../gcc/gcc/d/dmd/dstruct.c:292 0x63a8bf Module::semantic3(Scope*) ../../gcc/gcc/d/dmd/dmodule.c:814 0x72d7bd d_parse_file() ../../gcc/gcc/d/d-lang.cc:1201 |
May 19, 2019 Re: GDC 9 and ARM Cortex-M | ||||
---|---|---|---|---|
| ||||
Posted in reply to Timo Sintonen | On Sun, 19 May 2019 at 18:20, Timo Sintonen via D.gnu <d.gnu@puremagic.com> wrote: > > On Sunday, 19 May 2019 at 14:17:05 UTC, Iain Buclaw wrote: > > > > I don't really expect any part of druntime to build on bare metal. Too much depends on libc being available. > > I have done this several times so I mostly know what I am doing and I do understand that this may also be something in my local setup. > > > You could also use the new binaries I uploaded to compiler explorer for cross-checking whether the ICE is independently reproducible. > > > > https://explore.dgnu.org/z/WKKMCg > > > Cannot reproduce there. If you do not mind I include the long > version here. There is a failure in about 10 files and the others > pass. It seems it is the first function in the file. I do not > know if it is just because it is the first or is there something > inside that function. > (btw why the gdc title is printed twice) > I wouldn't know, I don't have any control over that bit. > arm-eabi-gdc -Wall -Wfatal-errors -O2 -frelease > -fversion=NoSystem -fno-bounds-check > -Wa,-ahls=rt/typeinfo/ti_Aint.o.l --verbose > -fno-moduleinfo -fversion=GNU_ARM_EABI_Unwinder > -fversion=STM32F4 -mcpu=cortex-m4 -mthumb -mfpu=fpv4-sp-d16 > -mfloat-abi=hard -c rt/typeinfo/ti_Aint.d -o > rt/typeinfo/ti_Aint.o > Using built-in specs. > COLLECT_GCC=arm-eabi-gdc > Target: arm-eabi > Configured with: ../gcc/configure --disable-bootstrap > --disable-nls --disable-werror --target=arm-eabi > --enable-languages=c,d --without-isl --without-cloog > --enable-multilib --disable-libphobos --disable-libstdcxx > --disable-libssp --disable-libquadmath --without-headers > --with-newlib --with-system-zlib > Thread model: single > gcc version 9.1.0 (GCC) > COLLECT_GCC_OPTIONS='-Wall' '-Wfatal-errors' '-O2' '-frelease' > '-fversion=NoSystem' '-fno-bounds-check' '-v' '-fno-moduleinfo' > '-fversion=GNU_ARM_EABI_Unwinder' '-fversion=STM32F4' > '-mcpu=cortex-m4' '-mthumb' '-mfpu=fpv4-sp-d16' > '-mfloat-abi=hard' '-c' '-o' 'rt/typeinfo/ti_Aint.o' > '-march=armv7e-m+fp' > /usr/local/libexec/gcc/arm-eabi/9.1.0/d21 rt/typeinfo/ti_Aint.d > -quiet -dumpbase ti_Aint.d -mcpu=cortex-m4 -mthumb > -mfpu=fpv4-sp-d16 -mfloat-abi=hard -march=armv7e-m+fp > -auxbase-strip rt/typeinfo/ti_Aint.o -O2 -Wall -Wfatal-errors > -version -frelease -fversion=NoSystem -fno-bounds-check > -fno-moduleinfo -fversion=GNU_ARM_EABI_Unwinder -fversion=STM32F4 > -imultilib cortex-m4/hardfp/fpv4 -v -o /tmp/ccuXKTnJ.s > GNU D (GCC) version 9.1.0 (arm-eabi) > compiled by GNU C version 8.2.0, GMP version 6.1.2, MPFR version > 4.0.1, MPC version 1.1.0, isl version none > GGC heuristics: --param ggc-min-expand=100 --param > ggc-min-heapsize=131072 > GNU D (GCC) version 9.1.0 (arm-eabi) > compiled by GNU C version 8.2.0, GMP version 6.1.2, MPFR version > 4.0.1, MPC version 1.1.0, isl version none > GGC heuristics: --param ggc-min-expand=100 --param > ggc-min-heapsize=131072 > binary /usr/local/libexec/gcc/arm-eabi/9.1.0/d21 > version v2.076.1 > predefs NoSystem GNU_ARM_EABI_Unwinder STM32F4 GNU D_Version2 > LittleEndian GNU_StackGrowsDown GNU_InlineAsm D_NoBoundsChecks > D_ModuleInfo D_Exceptions D_TypeInfo all ARM Thumb ARM_Thumb > ARM_HardFloat D_HardFloat CppRuntime_Gcc > parse ti_Aint > importall ti_Aint > import object (object.d) > import core.internal.hash (core/internal/hash.d) > import core.internal.traits (core/internal/traits.d) > import core.internal.convert (core/internal/convert.d) > import core.stdc.string (core/stdc/string.d) > semantic ti_Aint > semantic2 ti_Aint > semantic3 ti_Aint > d21: internal compiler error: Segmentation fault > 0xb1b98f crash_signal > ../../gcc/gcc/toplev.c:326 > 0x65327d Module::isRoot() > ../../gcc/gcc/d/dmd/module.h:143 Backtrace says that the 'this' pointer for Module is NULL. > 0x65327d TemplateInstance::appendToModuleMember() > ../../gcc/gcc/d/dmd/dtemplate.c:7444 Thereby, mi->importedFrom is NULL. It's not really obvious how that happens. Unless this is a module that managed to somehow not have semantic run on it, I would initially infer that some memory corruption had happened. What's the system compiler version you are using? I've tested with both gcc-9.1 and gcc-8.3, not able to reproduce. I've ignored the t-arm-elf modification for now, as that should not have any effect on the front-end. -- Iain. |
May 20, 2019 Re: GDC 9 and ARM Cortex-M | ||||
---|---|---|---|---|
| ||||
Posted in reply to Iain Buclaw | On Sunday, 19 May 2019 at 18:58:09 UTC, Iain Buclaw wrote: > > What's the system compiler version you are using? I've tested with both gcc-9.1 and gcc-8.3, not able to reproduce. It is in the dump above (even two times ;) >> GNU D (GCC) version 9.1.0 (arm-eabi) >> compiled by GNU C version 8.2.0, GMP version 6.1.2, MPFR version >> 4.0.1, MPC version 1.1.0, isl version none I'll try to update to 9.1 and test again |
May 20, 2019 Re: GDC 9 and ARM Cortex-M | ||||
---|---|---|---|---|
| ||||
Posted in reply to Timo Sintonen | On Mon, 20 May 2019 at 20:05, Timo Sintonen via D.gnu <d.gnu@puremagic.com> wrote: > > On Sunday, 19 May 2019 at 18:58:09 UTC, Iain Buclaw wrote: > > > > > What's the system compiler version you are using? I've tested with both gcc-9.1 and gcc-8.3, not able to reproduce. > > It is in the dump above (even two times ;) > > >> GNU D (GCC) version 9.1.0 (arm-eabi) > >> compiled by GNU C version 8.2.0, GMP version 6.1.2, > >> MPFR version > >> 4.0.1, MPC version 1.1.0, isl version none > > I'll try to update to 9.1 and test again > Or even just 8.3, I guess. -- Iain |
Copyright © 1999-2021 by the D Language Foundation