Open PathogenDavid opened 4 years ago
Some C++ compilers will sometimes generate an implicit constructor to handle this.
For example, x86-64 clang 10.0.0
on Godbolt produces:
Test(): # @Test()
push rbp
mov rbp, rsp
sub rsp, 16
lea rdi, [rbp - 8]
call DefaultImpl::DefaultImpl() [base object constructor]
lea rax, [rbp - 8]
mov rdi, rax
call UseAllocator(AbstractBase*)
add rsp, 16
pop rbp
ret
and x64 msvc v19.27
:
impl$ = 32
void Test(void) PROC ; Test
$LN3:
sub rsp, 56 ; 00000038H
lea rcx, QWORD PTR impl$[rsp]
call DefaultImpl::DefaultImpl(void)
lea rcx, QWORD PTR impl$[rsp]
call void UseAllocator(AbstractBase *) ; UseAllocator
add rsp, 56 ; 00000038H
ret 0
void Test(void) ENDP ; Test
This is blocking the use of PxDefaultAllocator
in PhysX. We should just leverage the inline export helper infrastructure for this.
Turns out this will be a bit of a pain since we can't synthesize TranslatedFunction
s and InlineExportHelper
assumes we have a `ClanSharp.FunctionDecl.
We'll probably need to add synthesizing functions (which is very odd outside this situation) as well as special-case for generating these trampolines. It might also be worth checking if Clang is internally synthesizing a constructor declaration or not so we can maybe avoid doing it ourselves.
I added a warning to CSharpTranslationVerifier
to help alert people to this missing feature and to make it easier to enumerate the types affected by it. (Although ideally we should just add this sooner rather than later.)
For types without constructors, the C++ compiler may initialize the vtable pointer wherever the type is initialized.
This was encountered with PxDefaultAllocator.
Here's a simple example: (Godbolt)
With GCC x86-64 10.2,
Test
is generated as follows:The easiest solution here is probably to use C trampolines for object construction (when necessary?)