On Wed, Feb 11, 2026 at 9:54 PM Damjan Jovanovic <[email protected]> wrote:
> > > On Tue, Feb 10, 2026 at 3:57 AM Damjan Jovanovic <[email protected]> > wrote: > >> >> >> On Sun, Feb 8, 2026 at 11:58 AM Pedro Lino via dev < >> [email protected]> wrote: >> >>> Hi Damjan >>> >>> > On 02/08/2026 9:32 AM WET Damjan Jovanovic <[email protected]> wrote: >>> > >>> > >>> > Hi >>> > >>> > I finally have some good news. >>> > >>> >>> <snip> >>> >>> > The test still crashes later on from something else, but it gets much >>> > further before that crash. >>> > >>> > In the next few days, I'll revisit the 127 commits I've got in my local >>> > amd64-bridge branch, clean them up, and push some of them to >>> > the windows-amd64 branch (from which it has been forked off). That >>> should >>> > make further debugging easier, and allow others to join the fun. >>> > >>> > There is still that next crash and any others to fix, then the >>> exception >>> > handling to get working, but the fact it's now successfully calling >>> several >>> > complex methods, with many parameters of various types and complex >>> return >>> > types, and getting the right results, is highly encouraging. A Win64 >>> > OpenOffice no longer seems that far away :-). >>> >>> Thank you for your persistence and for the good news! >>> >>> Looking forward to help with debugging and testing a Win x86-64 build! >>> >>> All the best, >>> Pedro >>> >>> >> Thank you. >> >> With extensive logging, I found and fixed another major bug. When >> complex types were being returned, the first 8 bytes were getting >> corrupted, because in call.asm function callVirtualMethod, for complex >> types, I was writing the contents of the RAX register into >> *pRegisterReturn, something that should only be done for simple types, as >> that memory already contains the value to return for complex types. >> >> Now all calling and returning tests seem to work :-), and the test is >> only crashing during exception handling. A little more logging and testing >> that, and we could have a perfectly working Windows/amd64 UNO bridge, and >> maybe even the Win64 OpenOffice starting up! >> >> Regards >> Damjan >> >> > Even exception handling is now largely working. The problem was the > assembly language function, callVirtualMethod, which needed stupid MASM > "pseudo-ops" and the function "epilog" changed to use only the allowed > instructions. This is because Win64 exception handling apparently needs > tons of static info to unwind the stack properly during exceptions, even > for assembly language functions that merely pass exceptions through and > never throw or catch them. > > In fact, of the 4 test functions in > TestBridgeImpl::run(), raiseException() and raiseOneWayException() are now > getting assertion errors and failing instead of crashing, and most > of performTest() is passing. The only parts of performTest() that crash are > the same part that also crashes on OS/2 and i386 FreeBSD, and then some > multiple inheritance tests. > > Maybe the Windows/amd64 UNO bridge is already good enough to run > OpenOffice? > > Regards > Damjan > > Hi I've pushed all my fixes so far into the windows-amd64 branch. The list of failing tests in main/testtools/source/bridgetest/bridgetest.cxx is now much smaller: - performTest(): the polystruct tests crash (where OS/2 and FreeBSD i386 also crash). - performTest(): the multiple inheritance tests crash (both cases crash). - performTest(): testConstructorService test crashes. - raiseException() fails. - raiseOnewayException() fails. However, running soffice.exe crashes almost immediately, so there are still major bugs to fix. You can test it yourself. Pass --enable-win64 to ./configure, and revert commit 57e08e4bf065d356442a241ce6ea54a955de853a if you want to run the testtools tests. Regards Damjan
