I had implemented a couple of basic things quite wrong, partly because
of easily misunderstood Microsoft documentation. A couple of things I
just had forgot to do properly.
Attempt to make the source code more consistent in spacing and
variable naming. Clean away meaningless vertical space wasting
non-verbal comments.
The bridgetest over in testtools now runs through quite a lot of its
paces successfully. But exception handling and RTTI, the stuff in
except.cxx, is still not really done at all. And even if I comment out
those checks in bridgetest so that no exceptios are thrown, I then get
a crash later.
It simplifies function table and unwinding info management, as those
are now static for the privateSnippetExecutor() function in
call.asm. Even if it is slightly ugly to have to poke in more
instructions in codeSnippet().
Out privateSnippetExecutor() is much simpler than the x64 Linux one,
thanks to the simpler calling convention.
Now the call through the trampoline into cpp_vtable_call() seems to
work, but I get a crash later. Glitches in parameter passing, no
doubt. Debugging needed in cpp_vtable_call() and cpp2uno_call().
The basic implementation is probably sane. But I wonder if I after all
should have done like in the x86-64 Linux implementation, with the
dynamically generated trampoline just jumping into fixed code shared
between all trampolines. Probably should redo it like that, yes.
Will it then cause a problem for OS unwinding if the caller of the
trampoline calls a short dynamically generated code snippet, which
then jumps into the fixed part, and only the fixed part has a
(assembler-generated) function table and unwind info? Probably not.
It is quite impossible that such a short dynamically generated snippet
with just a couple of instructions would cause an exception, and when
we have jumped into the fixed part, where the call to
cpp_vtable_call() is done, it doesn't matter any more that the caller
in fact didn't call what the function table claims is the entry
point. Or does it?
Doing it that way would mean no RtlAddFunctionTable() and
RtlDeleteFunctionTable() would be needed, and especially doing the
latter correctly is a bit hairy.
I think I might actually be able to manage without any assembly coding
here, thanks to the clean design of the x64 Windows calling
convention, and tricking the compiler (in a fully documented and
stable way) by using varargs. uno2cpp.cxx might even be getting close
to working now, but cpp2uno.cxx and except.cxx parts are just forced
to compile by using dummy code.
