extern(C++) multiple inheritence

[Manu via Digitalmars-d]

On 26 January 2016 at 15:20, Manu <turkeyman at gmail.com> wrote:
> On 26 January 2016 at 15:11, Walter Bright via Digitalmars-d
> <digitalmars-d at puremagic.com> wrote:
>> On 1/25/2016 9:02 PM, Manu via Digitalmars-d wrote:
>>>
>>> On 24 January 2016 at 20:40, Walter Bright via Digitalmars-d
>>> <digitalmars-d at puremagic.com> wrote:
>>>>
>>>> On 1/22/2016 5:46 PM, Manu via Digitalmars-d wrote:
>>>>>
>>>>>
>>>>> I brought a work laptop home this weekend in anticipation ;)
>>>>
>>>>
>>>>
>>>> Here ya go:
>>>>
>>>>    https://github.com/D-Programming-Language/dmd/pull/5364
>>>>
>>>> Be wary of:
>>>>
>>>>    https://issues.dlang.org/show_bug.cgi?id=15589
>>>>
>>>> and use the workaround as necessary. This is lower priority, so I won't
>>>> be
>>>> dealing with it for a bit.
>>>
>>>
>>> Next blocker: https://issues.dlang.org/show_bug.cgi?id=15610
>>>
>>> C++ methods with multiple-inheritence expect that 'this' is a pointer
>>> to the base class that introduced the function.
>>> When using C++ 'interface's, which C++ just treats like normal
>>> multiple-inheritence, C++ expects that the 'this' pointer is adjusted
>>> to the offset of the interface's vtable.
>>>
>>> If I have:
>>> extern(C++) interface Interface { voif f(); }
>>> extern(C++) class C : Base, Interface
>>> {
>>>    void f();
>>> }
>>>
>>> Calling c.f(), D is passing 'this' unaltered, but C++ expects 'this'
>>> is a pointer to 'Interface', and then it crashes accessing members at
>>> incorrect offsets.
>>>
>>
>> The PR 5364 does this. (And only Microsoft Win64 has this effect.)
>
> Oh okay. I thought that PR was about correctly locating the vtable and
> function offsets. I'll wait till that's merged.

Tried today's nightly (https://builds.dawg.eu/dmd-nightly/)
Built 27-Jan-2016 05:22, which is definitely after 5364 was merged
("committed 21 hours ago", which was during the 26th)
Still crashes. Setup looks similar; leading to the call, RAX is the
vtable and RCX is 'this', there is a moment prior to the call where
they are both correct for the call, and then there are few extra
opcodes which dereferences each of them until they are rubbish values,
then tries to make the call, which jumps to a bad address.

Bit of this: https://img42.com/oqN6y ;)

I am off work for 3 weeks from Friday, I don't think I have any more
time for this sadly.