D.gnu - GDC 9 and ARM Cortex-M
- Timo Sintonen (7/7) May 18 2019 I am updating my toolset and libraries to GCC/GDC 9.1 release.
- Johannes Pfau (12/20) May 19 2019 Cross-compilers in general are expected to work, but only basic testing
- Timo Sintonen (3/28) May 19 2019 It looks like there is an ice with several files in rt/typeinfo.
- Mike Franklin (12/19) May 19 2019 Several months ago, I used this script
- Timo Sintonen (32/49) May 19 2019 As we know there is always three possible sources of failure:
- Iain Buclaw (9/62) May 19 2019 You could also use the new binaries I uploaded to compiler explorer
- Timo Sintonen (102/108) May 19 2019 I have done this several times so I mostly know what I am doing
- Iain Buclaw (14/97) May 19 2019 I wouldn't know, I don't have any control over that bit.
- Timo Sintonen (3/9) May 20 2019 I'll try to update to 9.1 and test again
- Iain Buclaw (5/15) May 20 2019 Or even just 8.3, I guess.
- Timo Sintonen (8/27) May 22 2019 I updated my system with the newest packages and even built gcc
- Iain Buclaw (9/37) May 23 2019 Given the nature of the segfault your getting, I would expect that
- Timo Sintonen (13/18) Jun 08 2019 This problem exists in 7 typeinfo files and every time in getHash
- Timo Sintonen (12/16) Jul 06 2019 My little test program is nearly working now.
- Iain Buclaw (13/30) Jul 07 2019 Don't think that has anything to do with gdc.
- Timo Sintonen (15/51) Jul 07 2019 Am I picking the right value in gcc/unwind/arm.d line 54 and does
- Iain Buclaw (16/61) Jul 07 2019 The C code that's based off is:
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 18 2019
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
Timo Sintonen <t.sintonen luukku.com> 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:It looks like there is an ice with several files in rt/typeinfo. I'll make a bug report when I know more.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.
May 19 2019
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
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: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-zlibI 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
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: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. -- IainOn Sunday, 19 May 2019 at 06:54:14 UTC, Timo Sintonen wrote: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-zlibI 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
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/WKKMCgCannot 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
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 wouldn't know, I don't have any control over that bit.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/WKKMCgCannot 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:143Backtrace says that the 'this' pointer for Module is NULL.0x65327d TemplateInstance::appendToModuleMember() ../../gcc/gcc/d/dmd/dtemplate.c:7444Thereby, 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 19 2019
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 ;)I'll try to update to 9.1 and test againGNU 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
May 20 2019
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:Or even just 8.3, I guess. -- IainWhat'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 ;)I'll try to update to 9.1 and test againGNU 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
May 20 2019
On Monday, 20 May 2019 at 19:12:54 UTC, Iain Buclaw wrote:On Mon, 20 May 2019 at 20:05, Timo Sintonen via D.gnu <d.gnu puremagic.com> wrote:I updated my system with the newest packages and even built gcc 10 from master as host gcc. Still the same. I know I may have something like old headers somewhere... I may test with a fresh install at some point but for now I will just comment out the failing code and continue. I think there is no point to try gdc 10 now. When will the new frontend land into gcc master?On Sunday, 19 May 2019 at 18:58:09 UTC, Iain Buclaw wrote:Or even just 8.3, I guess.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 ;)I'll try to update to 9.1 and test againGNU 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
May 22 2019
On Thu, 23 May 2019 at 07:10, Timo Sintonen via D.gnu <d.gnu puremagic.com> wrote:On Monday, 20 May 2019 at 19:12:54 UTC, Iain Buclaw wrote:Given the nature of the segfault your getting, I would expect that you'd get the same problem even if the sources were in D. It is _not_ normal for a module->importedFrom to be NULL or an invalid pointer. Something must have gone horribly awry in memory for that to happen. -- IainOn Mon, 20 May 2019 at 20:05, Timo Sintonen via D.gnu <d.gnu puremagic.com> wrote:I updated my system with the newest packages and even built gcc 10 from master as host gcc. Still the same. I know I may have something like old headers somewhere... I may test with a fresh install at some point but for now I will just comment out the failing code and continue. I think there is no point to try gdc 10 now. When will the new frontend land into gcc master?On Sunday, 19 May 2019 at 18:58:09 UTC, Iain Buclaw wrote:Or even just 8.3, I guess.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 ;)I'll try to update to 9.1 and test againGNU 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
May 23 2019
On Thursday, 23 May 2019 at 07:19:23 UTC, Iain Buclaw wrote:Given the nature of the segfault your getting, I would expect that you'd get the same problem even if the sources were in D. It is _not_ normal for a module->importedFrom to be NULL or an invalid pointer. Something must have gone horribly awry in memory for that to happen.This problem exists in 7 typeinfo files and every time in getHash function. All other files compiles fine. I can live without these now. When is getHash called? By compiler or by user? What does option -fno-rtti exactly do and what D features are not available? I noticed this with -fno-rtti: int * i = new int; // <-- compiler error myclass c = new myclass(); // <-- passes, dies at runtime There were big changes in exception handling code about 2 years ago and my exception code stopped to work. What was changed back then? How can I get my code to work again? Could this be some struct alignment problem like some years ago?
Jun 08 2019
My little test program is nearly working now. Some funny things I have found: - When not using -O2 4 extra bytes appear in front of tdata init values. With -O2 they disappear. - I have my own calloc where I first allocate a block with malloc and then use memset to zero it. GCC can see this and replaces these two calls with a call to calloc...There were big changes in exception handling code about 2 years ago and my exception code stopped to work. What was changed back then? How can I get my code to work again? Could this be some struct alignment problem like some years ago?The program dies somewhere in unwinding code. It looks like the stack pointer is moved incorrectly and values are popped to wrong registers in function return. There might be a size mismatch between c and d side when function arguments are passed in stack. Any idea where to look?
Jul 06 2019
On Sun, 7 Jul 2019 at 08:25, Timo Sintonen via D.gnu <d.gnu puremagic.com> wrote:My little test program is nearly working now. Some funny things I have found: - When not using -O2 4 extra bytes appear in front of tdata init values. With -O2 they disappear.Don't think that has anything to do with gdc.- I have my own calloc where I first allocate a block with malloc and then use memset to zero it. GCC can see this and replaces these two calls with a call to calloc...Use -fno-builtin to disable C function recognition.The only recent change that would have affected ABI is the addition of the general-regs-only attribute added for ARM EABI. As far as I still know - and I have done testing on my phone that sports a Cortex-A53 - the unwind routines for gdc work well. I'm not aware of there being any differences between ARM targets regarding type sizes. Function and type definitions are in gcc/unwind/arm_commond.d, and that has been translated from gcc/ginclude/unwind-arm-common.h. -- IainThere were big changes in exception handling code about 2 years ago and my exception code stopped to work. What was changed back then? How can I get my code to work again? Could this be some struct alignment problem like some years ago?The program dies somewhere in unwinding code. It looks like the stack pointer is moved incorrectly and values are popped to wrong registers in function return. There might be a size mismatch between c and d side when function arguments are passed in stack. Any idea where to look?
Jul 07 2019
On Sunday, 7 July 2019 at 09:57:33 UTC, Iain Buclaw wrote:On Sun, 7 Jul 2019 at 08:25, Timo Sintonen via D.gnu <d.gnu puremagic.com> wrote:Am I picking the right value in gcc/unwind/arm.d line 54 and does that matter? With hex dump of the stack and map file I was able to manually create trace: _d_dynamic cast gcc.deh.actionTableLookup gcc.deh.scan gcc.deh.__gdc_personality __gdc_personality_v0 __gnu_unwind_raiseException unwind_raiseException _d_throw myThrowingFunction mainMy little test program is nearly working now. Some funny things I have found: - When not using -O2 4 extra bytes appear in front of tdata init values. With -O2 they disappear.Don't think that has anything to do with gdc.- I have my own calloc where I first allocate a block with malloc and then use memset to zero it. GCC can see this and replaces these two calls with a call to calloc...Use -fno-builtin to disable C function recognition.The only recent change that would have affected ABI is the addition of the general-regs-only attribute added for ARM EABI. As far as I still know - and I have done testing on my phone that sports a Cortex-A53 - the unwind routines for gdc work well. I'm not aware of there being any differences between ARM targets regarding type sizes. Function and type definitions are in gcc/unwind/arm_commond.d, and that has been translated from gcc/ginclude/unwind-arm-common.h.There were big changes in exception handling code about 2 years ago and my exception code stopped to work. What was changed back then? How can I get my code to work again? Could this be some struct alignment problem like some years ago?The program dies somewhere in unwinding code. It looks like the stack pointer is moved incorrectly and values are popped to wrong registers in function return. There might be a size mismatch between c and d side when function arguments are passed in stack. Any idea where to look?
Jul 07 2019
On Sun, 7 Jul 2019 at 14:15, Timo Sintonen via D.gnu <d.gnu puremagic.com> wrote:On Sunday, 7 July 2019 at 09:57:33 UTC, Iain Buclaw wrote:The C code that's based off is: #if (defined(linux) && !defined(__uClinux__)) || defined(__NetBSD__) \ || defined(__FreeBSD__) || defined(__fuchsia__) #define _GLIBCXX_OVERRIDE_TTYPE_ENCODING (DW_EH_PE_pcrel | DW_EH_PE_indirect) #elif defined(__symbian__) || defined(__uClinux__) #define _GLIBCXX_OVERRIDE_TTYPE_ENCODING (DW_EH_PE_absptr) #else #define _GLIBCXX_OVERRIDE_TTYPE_ENCODING (DW_EH_PE_pcrel) #endif You could just omit setting '_TTYPE_ENCODING' and see what happens. The personality routine doesn't use it to override the inferred encoding if it doesn't exist. -- IainOn Sun, 7 Jul 2019 at 08:25, Timo Sintonen via D.gnu <d.gnu puremagic.com> wrote:Am I picking the right value in gcc/unwind/arm.d line 54 and does that matter?My little test program is nearly working now. Some funny things I have found: - When not using -O2 4 extra bytes appear in front of tdata init values. With -O2 they disappear.Don't think that has anything to do with gdc.- I have my own calloc where I first allocate a block with malloc and then use memset to zero it. GCC can see this and replaces these two calls with a call to calloc...Use -fno-builtin to disable C function recognition.The only recent change that would have affected ABI is the addition of the general-regs-only attribute added for ARM EABI. As far as I still know - and I have done testing on my phone that sports a Cortex-A53 - the unwind routines for gdc work well. I'm not aware of there being any differences between ARM targets regarding type sizes. Function and type definitions are in gcc/unwind/arm_commond.d, and that has been translated from gcc/ginclude/unwind-arm-common.h.There were big changes in exception handling code about 2 years ago and my exception code stopped to work. What was changed back then? How can I get my code to work again? Could this be some struct alignment problem like some years ago?The program dies somewhere in unwinding code. It looks like the stack pointer is moved incorrectly and values are popped to wrong registers in function return. There might be a size mismatch between c and d side when function arguments are passed in stack. Any idea where to look?
Jul 07 2019