GDC 9 and ARM Cortex-M

[Iain Buclaw]

On Sun, 7 Jul 2019 at 14:15, Timo Sintonen via D.gnu
<d.gnu at 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 at 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