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:
>>
>> 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.

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 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:
> > 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.
>
> 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?
>

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.

-- 
Iain

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?

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?

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.

> >
> > 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?
>

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.

-- 
Iain

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:
>>
>> 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.
>
>> >
>> > 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?
>>
>
> 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.

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
main

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:
> > 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.
> >
> >> >
> >> > 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?
> >>
> >
> > 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.
>
> Am I picking the right value in gcc/unwind/arm.d line 54 and does that matter?
>

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.

-- 
Iain