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
