Hi, In my OS project I started using struct destructors, and when using them for the first time, using them triggered a link error, reporting that `_d_eh_personality` is missing.

I stubbed the function using `extern (C) int _d_eh_personality(int a, int b, void* c, int d, void* e) { assert(0); }`, this works for release builds, but as soon as I add `-d-debug` to the flags I use, the signature stops being valid and fails compilation with `Error: Incompatible declaration of runtime function _d_eh_personality`, when compiling the same function.

What prototypes should I be stubbing to get this to work? Why are this function required when dealing with struct destructors?
I'm using LDC 1.21.0 with LLVM 10.0.0

On Sunday, 31 May 2020 at 08:41:32 UTC, Streaksu wrote:
> Hi, In my OS project I started using struct destructors, and when using them for the first time, using them triggered a link error, reporting that `_d_eh_personality` is missing.
>
> I stubbed the function using `extern (C) int _d_eh_personality(int a, int b, void* c, int d, void* e) { assert(0); }`, this works for release builds, but as soon as I add `-d-debug` to the flags I use, the signature stops being valid and fails compilation with `Error: Incompatible declaration of runtime function _d_eh_personality`, when compiling the same function.
>
> What prototypes should I be stubbing to get this to work? Why are this function required when dealing with struct destructors?
> I'm using LDC 1.21.0 with LLVM 10.0.0

Forgot to mention I'm using betterC with `-betterC`, sorry for the inconvenience

Please post some corresponding code. AFAIK, there's no exception support at all with -betterC, so the personality function shouldn't be referenced. [The correct signature would be https://github.com/ldc-developers/druntime/blob/9cfc7fa48cf868f91af9290764eccb5db4b2877c/src/rt/dwarfeh.d#L506-L508.]

On Sunday, 31 May 2020 at 14:18:17 UTC, kinke wrote:
> Please post some corresponding code. AFAIK, there's no exception support at all with -betterC, so the personality function shouldn't be referenced. [The correct signature would be https://github.com/ldc-developers/druntime/blob/9cfc7fa48cf868f91af9290764eccb5db4b2877c/src/rt/dwarfeh.d#L506-L508.]

The easiest way I found of triggering the error is adding this destructor to this struct https://pastebin.com/6rypx3yA , the templates used have no effect on the error as they are used on other struct destructors and they dont trigger this error, its just in this namely case, their definitions anyways are available at https://github.com/Takao-OS/Takao/blob/master/source/lib/alloc.d.

Lately I discovered this dependency is also generated in other points of my codebase, namely in https://github.com/Takao-OS/Takao/blob/master/source/system/apic.d, which makes use of core.volatile (it might have something to do in that case I think).

Those 2 instances, that class and the later apic.d are the only examples I could find of this function being generated.

On Monday, 1 June 2020 at 04:28:32 UTC, Streaksu wrote:
> The easiest way I found of triggering the error is adding this destructor to this struct https://pastebin.com/6rypx3yA , the templates used have no effect on the error as they are used on other struct destructors and they dont trigger this error, its just in this namely case, their definitions anyways are available at https://github.com/Takao-OS/Takao/blob/master/source/lib/alloc.d.
>
> Lately I discovered this dependency is also generated in other points of my codebase, namely in https://github.com/Takao-OS/Takao/blob/master/source/system/apic.d, which makes use of core.volatile (it might have something to do in that case I think).
>
> Those 2 instances, that class and the later apic.d are the only examples I could find of this function being generated.

Your current Takao master compiles & links fine for me (`make`) with LDC v1.21.

The Window struct code is incomplete, adding some imports wasn't enough - where's plotString and windowBorder?

On Monday, 1 June 2020 at 13:33:20 UTC, kinke wrote:
> Your current Takao master compiles & links fine for me (`make`) with LDC v1.21.

Ah, found the stub and removed it, now I see the ref in apic.o.

On Monday, 1 June 2020 at 04:28:32 UTC, Streaksu wrote:
> Lately I discovered this dependency is also generated in other points of my codebase, namely in https://github.com/Takao-OS/Takao/blob/master/source/system/apic.d, which makes use of core.volatile (it might have something to do in that case I think).

Looks like a frontend issue. While any manual try/finally is stripped by the frontend for -betterC code (e.g., see AST of https://run.dlang.io/is/WEEFFc), it inserts a try/finally into 3 functions in your system/apic.d (append -vcg-ast to the cmdline to have the compiler generate a system/apic.d.cg).

On Monday, 1 June 2020 at 13:33:20 UTC, kinke wrote:
> On Monday, 1 June 2020 at 04:28:32 UTC, Streaksu wrote:
>> [...]
>
> Your current Takao master compiles & links fine for me (`make`) with LDC v1.21.
>
> The Window struct code is incomplete, adding some imports wasn't enough - where's plotString and windowBorder?

The window code is code I'm working on right now that is not into master, I will push it right now as it could be useful.

On Monday, 1 June 2020 at 14:13:44 UTC, kinke wrote:
> On Monday, 1 June 2020 at 04:28:32 UTC, Streaksu wrote:
>> Lately I discovered this dependency is also generated in other points of my codebase, namely in https://github.com/Takao-OS/Takao/blob/master/source/system/apic.d, which makes use of core.volatile (it might have something to do in that case I think).
>
> Looks like a frontend issue. While any manual try/finally is stripped by the frontend for -betterC code (e.g., see AST of https://run.dlang.io/is/WEEFFc), it inserts a try/finally into 3 functions in your system/apic.d (append -vcg-ast to the cmdline to have the compiler generate a system/apic.d.cg).

Then is this a compiler bug? Or something I should approach by other coding practices. Thanks for the help so far btw.

On Tuesday, 2 June 2020 at 06:19:56 UTC, Streaksu wrote:
> Then is this a compiler bug? Or something I should approach by other coding practices. Thanks for the help so far btw.

Yes, a compiler bug. You could help by trying to reduce it to a single-file test case and then filing a DMD issue about it.