Exceptions in ARM

[Timo Sintonen]

On Saturday, 1 March 2014 at 10:49:57 UTC, Johannes Pfau wrote:
> On Saturday, 1 March 2014 at 09:24:40 UTC, Mike wrote:
>> On Saturday, 1 March 2014 at 08:56:26 UTC, Timo Sintonen wrote:
>>> There is nothing interesting in the assembly, only this wrong
>>> call.
>>> This form of instruction is just missing in M4 and it gives an
>>> invalid instruction fault. So what are we arguing about?
>>>
>>> If this is so hard for us to find, no wonder the compiler 
>>> writers
>>> have not noticed this.
>>
>> Well, I yield then to the compiler folks.  Hopefully Iain or
>> Johannes can provide some insight.
>
> AFAIK the call to _Unwind_RaiseException [1] is just a normal 
> function call [2] to a extern(C) function in a different 
> compilation unit. It's not even a builtin so it doesn't look 
> like a gdc bug. GCC bug is more likely but I wonder what 
> exactly makes this case special? Why does this not happen for 
> every function call to a extern(C) function?
>
> Please try the following:
> * Verify your --with-cpu, --with-arch, --with-tune flags for 
> gcc configure. Also make sure that binutils is configured with 
> the correct flags.
> * Have a look at the build log how gcc/deh.d is compiled. Use 
> the same compile command, but generate assembly via -S. Then 
> look at the asm code to check whether the compiler or the 
> assembler/linker is to blame.
> * Try to reduce the example / understand why exactly this 
> happens only in this case.
> * When you have a reduced example, try to port it to C and see 
> if GCC handles it correctly.
>
>
> [1] 
> https://github.com/D-Programming-GDC/GDC/blob/master/libphobos/libdruntime/gcc/deh.d#L151
> [2] 
> https://github.com/D-Programming-GDC/GDC/blob/master/libphobos/libdruntime/gcc/unwind/arm.d#L191

I checked my code and the library code and there is no other call 
like this. I think there is one thing that makes this function 
special: if I understand correct, this function will not return. 
If there is some noreturn attribute somewhere this function might 
be handled in a different way.

Is it so that gdc does not generate any assembly directly? So 
this would be a bug in gcc side and I may report it there.