Apache OpenOffice (AOO) Bugzilla – Issue 24507
linux sparc UNO Changes for Multiple-Inheritance Interface Types
Last modified: 2004-04-20 19:59:42 UTC
For linux sparc I have done most of the editing, copied from linux/intel but I have not tried the assembler portions. My diff is attached. The build fails here making uno2cpp: /home/jim/680/o2_src/solver/680/unxlngs.pro/inc/com/sun/star/uno/genfunc.h:79: error: syntax error before `(' token The lines from genfunc.h: inline void SAL_CALL cpp_acquire( void * pCppI ) SAL_THROW( () ); I guess it doesnt know about SAL_CALL? Full error log also attached.
Created attachment 12536 [details] build errors
Created attachment 12537 [details] complete bridges diff
Created attachment 12542 [details] my uno2cpp.cxx
Created attachment 12543 [details] my cpp2uno.cxx
Help with assembler code would be appreciated - in cpp2uno.cxx lines 284-289 and lines from 406.
I wonder am i building this right? I ead back over the emails and noticed i need more than just bridges code. I did cvs update -dP -r cws_src680_sb10 for modules cppu, cppuhelper, registry, bridges. For bridges the new code is in the attic so i got that all by finding the latest version on the CVS web pages then cvs update -r [version] [filename]. Then i did cd into each of those modules rm -rf unxlngs.pro. Then cd into bridges and build --all. Got to cppuhelper: /home/jim/680/o2_src/cppuhelper/source ------------------------------ Making: ../unxlngs.pro/misc/cppuhelper.dpc Making : Dependencies touch ../unxlngs.pro/misc/cppuhelper.dpc cppumaker @/tmp/mkYn2Kq6 cppumaker ERROR: cannot dump Type 'com.sun.star.reflection.XInterfaceTypeDescription2' dmake: Error code 99, while making '../unxlngs.pro/inc/com/sun/star/registry/XSimpleRegistry.hpp' dmake: '../unxlngs.pro/inc/com/sun/star/registry/XSimpleRegistry.hpp' removed. ---* TG_SLO.MK *--- ERROR: Error 65280 occurred while making /home/jim/680/o2_src/cppuhelper/source jim@sun:~/680/o2_src/bridges$
Hi Jim, I looked at your diff, some thing I noticed. - you did not change from CPPU_CURRENT_NAMESPACE to an anonymous one as Stephan did (I think we should try to keep the code a close as possible to each other for support sake). - your code snippet (ie. assembler) must now do everything it did before plus pass in one more item to cpp_vtable_call In my case it now does: /* generate this code */ // # so first save gpr 3 to gpr 10 (aligned to 4) // stw r3,-2048(r1) // stw r4,-2044(r1) // stw r5,-2040(r1) // stw r6,-2036(r1) // stw r7,-2032(r1) // stw r8,-2028(r1) // stw r9,-2024(r1) // stw r10,-2020(r1) // # next save fpr 1 to fpr 8 (aligned to 8) // stfd f1,-2016(r1) // stfd f2,-2008(r1) // stfd f3,-2000(r1) // stfd f4,-1992(r1) // stfd f5,-1984(r1) // stfd f6,-1976(r1) // stfd f7,-1968(r1) // stfd f8,-1960(r1) // # now here is where cpp_vtable_call must go // lis r3,-8531 // ori r3,r3,48879 // mtctr r3 // # now load up the functionIndex // lis r3,-8531 // ori r3,r3,48879 // # now load up the vtableOffset // lis r4,-8531 // ori r4,r4,48879 // #now load up the pointer to the saved gpr registers // addi r5,r1,-2048 // #now load up the pointer to the saved fpr registers // addi r6,r1,-2016 // #now load up the pointer to the overflow call stack // addi r7,r1,8 // bctr To match the new signature of cpp_vtable_call. The only change to the assembler was handling both functionIndex and vtableOffset (and the resulting shift in registers that created). So you should modify your assembler anippet to pass in functionIndex (with the high bit properly set for complex return), vtableOffset, and the current stack pointer instead of just nTablePos and the current stack pointer. It also looks like cpp_vtable_call has some assmembler to fixup registers that were modified in the snippet so that would have to be changed as well. I just don't know what registers should be used in your case %o0, %o1, %o2? Perhaps writing a simple C program that passes in two int32 followed by a void pointer and compiling it and then disassembling it using objdump will show you exactly what needs to be done to properly pass 3 things instead of two, and should also give you the instruction codes to do it. Hope this helps, Kevin
Stephan, this seems to be yours :-).
.
I will own this issue because it is a task to manage my changes, and will cc to sb when i need help.
my task
Some more help is sought for the snippets - I have got halfway there... ============================== Here are the existing snippets: ============================== *codeSnip++ = 0xd023a044; *codeSnip++ = 0xd223a048; *codeSnip++ = 0xd423a04c; *codeSnip++ = 0xd623a050; *codeSnip++ = 0xd823a054; *codeSnip++ = 0xda23a058; *codeSnip++ = 0x9210000e; *codeSnip++ = 0x11000000 | ( nTablePos >> 10 ); *codeSnip++ = 0x90122000 | ( nTablePos & 1023 ); *codeSnip++ = 0x15000000 | ( ((unsigned long)cpp_vtable_call) >> 10 ); *codeSnip++ = 0x9412a000 | ( ((unsigned long)cpp_vtable_call) & 1023 ); *codeSnip++ = 0x81c28000; *codeSnip++ = 0x01000000; ==================================== Now i can build this assembler file: ==================================== st %o0, [%sp+68] st %o1, [%sp+72] st %o2, [%sp+76] st %o3, [%sp+80] st %o4, [%sp+84] st %o5, [%sp+88] mov %sp, %o1 sethi %hi( functionIndex ), %o0 sethi %hi( vtableOffset ), %o2 sethi %hi( cpp_vtable_call ), %l0 jmp %l0 nop =================== This is the result: =================== jim@sun:~/680/o2_src/bridges$ objdump -d hisnippet.o hisnippet.o: file format elf32-sparc Disassembly of section .text: 00000000 <.text>: 0: d0 23 a0 44 st %o0, [ %sp + 0x44 ] 4: d2 23 a0 48 st %o1, [ %sp + 0x48 ] 8: d4 23 a0 4c st %o2, [ %sp + 0x4c ] c: d6 23 a0 50 st %o3, [ %sp + 0x50 ] 10: d8 23 a0 54 st %o4, [ %sp + 0x54 ] 14: da 23 a0 58 st %o5, [ %sp + 0x58 ] 18: 92 10 00 0e mov %sp, %o1 1c: 11 00 00 00 sethi %hi(0), %o0 20: 15 00 00 00 sethi %hi(0), %o2 24: 21 00 00 00 sethi %hi(0), %l0 28: 81 c4 00 00 jmp %l0 2c: 01 00 00 00 nop ============================== So i can see lines 0-18 are the same as existing snippets. And the last two lines almost same. So far so good. ========================= These are Kevins instructions sethi %hi( functionIndex ), %o0 prepare functionIndex or %lo( functionIndex ), %o0 both hi and lo parts sethi %hi( vtableOffset ), %o2 prepare vtableOffset or %lo( vtableOffset ), %o2 both hi and lo parts sethi $hi( cpp_vtable_call ), %l0 or %l0, %lo( cpp_vtable_call ), %l0 But those lines starting with "or" give Error: Illegal operands Am I reading it wrongly or can you dervive the remaing snippets from the output? thanks, jim
Created attachment 12636 [details] to build offapi
My build stopped in offapi/drafts/com/sun/star/form/ListEntrySource.idl. This tries to include a file that has been removed in cws_src680_sb10. #include <drafts/com/sun/star/form/XListEntryBroadcaster.idl> see attached offapi.patch. I have not made an issue for this because this is not a standard building setup.
Progress report. I have build bridges now. Problem building tests in multinherit ===================================== jim@sun:~/680/o2_src/bridges/test/java_uno/multinherit$ ls CVS testmultinherit.cxx testmultinherit.map makefile.mk TestMultInherit.java types.idl readme.txt testmultinherit.LINUXIgcc3.map jim@sun:~/680/o2_src/bridges/test/java_uno/multinherit$ dmake Making dpj... rm ../../../unxlngs.pro/bin/test_javauno_multinherit.rdb rm: cannot remove `../../../unxlngs.pro/bin/test_javauno_multinherit.rdb': No such file or directory mkdir ../../../unxlngs.pro/misc/test_javauno_multinherit mkdir: cannot create directory `../../../unxlngs.pro/misc/test_javauno_multinherit': File exists mkdir ../../../unxlngs.pro/misc/test_javauno_multinherit/inc mkdir: cannot create directory `../../../unxlngs.pro/misc/test_javauno_multinherit/inc': File exists idlc -I/home/jim/680/o2_src/solver/680/unxlngs.pro/idl -O../../../unxlngs.pro/misc/test_javauno_multinherit ./types.idl idlc: compile './types.idl' ... idlc: detected 5 warnings compiling file './types.idl' idlc: returned successful Sun Microsystems (R) idlc Version 1.0 regmerge ../../../unxlngs.pro/bin/test_javauno_multinherit.rdb /UCR ../../../unxlngs.pro/misc/test_javauno_multinherit/types.urd merging registry "../../../unxlngs.pro/misc/test_javauno_multinherit/types.urd" under key "/UCR" in registry "../../../unxlngs.pro/bin/test_javauno_multinherit.rdb". cppumaker -BUCR -C -O../../../unxlngs.pro/misc/test_javauno_multinherit/inc ../../../unxlngs.pro/bin/test_javauno_multinherit.rdb -X/home/jim/680/o2_src/solver/680/unxlngs.pro/bin/types.rdb javamaker -BUCR -nD -O../../../unxlngs.pro/class ../../../unxlngs.pro/bin/test_javauno_multinherit.rdb -X/home/jim/680/o2_src/solver/680/unxlngs.pro/bin/types.rdb regmerge ../../../unxlngs.pro/bin/test_javauno_multinherit.rdb / /home/jim/680/o2_src/solver/680/unxlngs.pro/bin/types.rdb merging registry "/home/jim/680/o2_src/solver/680/unxlngs.pro/bin/types.rdb" under key "/" in registry "../../../unxlngs.pro/bin/test_javauno_multinherit.rdb". regcomp -register -r ../../../unxlngs.pro/bin/test_javauno_multinherit.rdb -c acceptor.uno.so \ -c bridgefac.uno.so -c connector.uno.so \ -c remotebridge.uno.so -c uuresolver.uno.so > sizeof(AlignSize_Impl) = 16 > sizeof(M) = 8 > sizeof(N) = 12 > sizeof(N2) = 12 > sizeof(O) = 16 > sizeof(D) = 8 > sizeof(C1) = 2 > sizeof(C2) = 8 > sizeof(C3) = 24 > sizeof(C4) = 40 > sizeof(C5) = 56 > sizeof(C6) = 72 > sizeof(O2) = 24 > sizeof(Char3) = 3 > sizeof(P) = 24 > sizeof(second) = 4 register component 'acceptor.uno.so' in registry '../../../unxlngs.pro/bin/test_javauno_multinherit.rdb' succesful! register component 'bridgefac.uno.so' in registry '../../../unxlngs.pro/bin/test_javauno_multinherit.rdb' failed! error (CannotRegisterImplementationException): loading component library failed: bridgefac.uno.so register component 'connector.uno.so' in registry '../../../unxlngs.pro/bin/test_javauno_multinherit.rdb' succesful! register component 'remotebridge.uno.so' in registry '../../../unxlngs.pro/bin/test_javauno_multinherit.rdb' failed! error (CannotRegisterImplementationException): loading component library failed: remotebridge.uno.so register component 'uuresolver.uno.so' in registry '../../../unxlngs.pro/bin/test_javauno_multinherit.rdb' failed! error (CannotRegisterImplementationException): loading component library failed: uuresolver.uno.so dmake: Error code 3, while making '../../../unxlngs.pro/bin/test_javauno_multinherit.rdb' dmake: '../../../unxlngs.pro/bin/test_javauno_multinherit.rdb' removed. ---* TG_SLO.MK *--- jim@sun:~/680/o2_src/bridges/test/java_uno/multinherit$ Also, cpputest gices "Segfault" but if I make cppu with debug=true then it reports: Checking DLL ../unxlngs.pro/lib/check_libcppu.so.3.1.0 ...> sizeof(AlignSize_Impl) = 16 > sizeof(M) = 8 > sizeof(N) = 12 > sizeof(N2) = 12 > sizeof(O) = 16 > sizeof(D) = 8 > sizeof(C1) = 2 > sizeof(C2) = 8 > sizeof(C3) = 24 > sizeof(C4) = 40 > sizeof(C5) = 56 > sizeof(C6) = 72 > sizeof(O2) = 24 > sizeof(Char3) = 3 > sizeof(P) = 24 > sizeof(second) = 4 : ok and cpputest:jim@sun:~/680/o2_src/cppu/unxlngs.pro/bin$ ./testcppu > sizeof(AlignSize_Impl) = 16 > sizeof(M) = 8 > sizeof(N) = 12 > sizeof(N2) = 12 > sizeof(O) = 16 > sizeof(D) = 8 > sizeof(C1) = 2 > sizeof(C2) = 8 > sizeof(C3) = 24 > sizeof(C4) = 40 > sizeof(C5) = 56 > sizeof(C6) = 72 > sizeof(O2) = 24 > sizeof(Char3) = 3 > sizeof(P) = 24 > sizeof(second) = 4 Segmentation fault Does this indicate anything about bridges yet?
need add remotebridges to the build list
First test :) jim@sun:~/680/o2_src/bridges/unxlngs.pro/bin$ ./testmultinherit-native-server & [1] 21178 jim@sun:~/680/o2_src/bridges/unxlngs.pro/bin$ > sizeof(AlignSize_Impl) = 16 > sizeof(M) = 8 > sizeof(N) = 12 > sizeof(N2) = 12 > sizeof(O) = 16 > sizeof(D) = 8 > sizeof(C1) = 2 > sizeof(C2) = 8 > sizeof(C3) = 24 > sizeof(C4) = 40 > sizeof(C5) = 56 > sizeof(C6) = 72 > sizeof(O2) = 24 > sizeof(Char3) = 3 > sizeof(P) = 24 > sizeof(second) = 4 > accepting socket,host=localhost,port=2002... jim@sun:~/680/o2_src/bridges/unxlngs.pro/bin$ ./testmultinherit-native-client > sizeof(AlignSize_Impl) = 16 > sizeof(M) = 8 > sizeof(N) = 12 > sizeof(N2) = 12 > sizeof(O) = 16 > sizeof(D) = 8 > sizeof(C1) = 2 > sizeof(C2) = 8 > sizeof(C3) = 24 > sizeof(C4) = 40 > sizeof(C5) = 56 > sizeof(C6) = 72 > sizeof(O2) = 24 > sizeof(Char3) = 3 > sizeof(P) = 24 > sizeof(second) = 4 connection established.Trace Message: > inserting new mapping: ;uno[70c6c2e0];urp[70c43c50] Trace Message: > inserting new mapping: ;gcc3[70c6b5b8];uno[70c6c2e0] Trace Message: > inserting new mapping: ;gcc3[70c6b5b8];urp[70c43c50] Trace Message: > inserting new mapping: ;urp[70c43c50];uno[70c6c2e0] Trace Message: > revoking mapping ;gcc3[70c6b5b8];urp[70c43c50] Trace Message: > inserting new mapping: ;uno[70cb0628];gcc3[70c7b8b8] Trace Message: > inserting new mapping: ;urp[70c751e0];uno[70cb0628] Trace Message: > inserting new mapping: ;urp[70c751e0];gcc3[70c7b8b8] Trace Message: > inserting new mapping: ;uno[70cb0628];urp[70c751e0] ./testmultinherit-native-client: line 1: 21188 Bus error uno -c com.sun.star.test.bridges.testmultinherit.impl -l testmultinherit.uno.so -ro test_javauno_multinherit.rdb -- "uno:socket,host=localhost,port=2002;urp;test" jim@sun:~/680/o2_src/bridges/unxlngs.pro/bin$ (tid=2) Unexpected connection closure Trace Message: > revoking mapping ;gcc3[70c6b5b8];uno[70c6c2e0] Trace Message: > revoking mapping ;uno[70c6c2e0];urp[70c43c50] Trace Message: > revoking mapping ;urp[70c43c50];uno[70c6c2e0] 1 Threads left [1]+ Done ./testmultinherit-native-server jim@sun:~/680/o2_src/bridges/unxlngs.pro/bin$
jim@sun:~/680/o2_src/bridges/unxlngs.pro/bin$ testmultinherit-java-server& [1] 21465 jim@sun:~/680/o2_src/bridges/unxlngs.pro/bin$ Server: Accepting... jim@sun:~/680/o2_src/bridges/unxlngs.pro/bin$ testmultinherit-native-client > sizeof(AlignSize_Impl) = 16 > sizeof(M) = 8 > sizeof(N) = 12 > sizeof(N2) = 12 > sizeof(O) = 16 > sizeof(D) = 8 > sizeof(C1) = 2 > sizeof(C2) = 8 > sizeof(C3) = 24 > sizeof(C4) = 40 > sizeof(C5) = 56 > sizeof(C6) = 72 > sizeof(O2) = 24 > sizeof(Char3) = 3 > sizeof(P) = 24 > sizeof(second) = 4 Server: ...connected... Server: ...bridged. Trace Message: > inserting new mapping: ;uno[70cb0628];gcc3[70c7b8a8] Trace Message: > inserting new mapping: ;urp[70c751e0];uno[70cb0628] Trace Message: > inserting new mapping: ;urp[70c751e0];gcc3[70c7b8a8] Trace Message: > inserting new mapping: ;uno[70cb0628];urp[70c751e0] ./testmultinherit-native-client: line 1: 21482 Bus error uno -c com.sun.star.test.bridges.testmultinherit.impl -l testmultinherit.uno.so -ro test_javauno_multinherit.rdb -- "uno:socket,host=localhost,port=2002;urp;test" jim@sun:~/680/o2_src/bridges/unxlngs.pro/bin$ testmultinherit-java-client Server: ...connected... Server: ...bridged. waiting for gc Client and server both cleanly terminate now: Success [1]+ Done testmultinherit-java-server jim@sun:~/680/o2_src/bridges/unxlngs.pro/bin$
i wonder are these relevant? testtools servicetests Job -o testtools.servicetests.LocalServiceTest successful executed Job -o testtools.servicetests.RemoteServiceTest successful executed jim@sun:~/680/o2_src/testtools/source/servicetests$ ======================================= Cannot build testtools bridgetests yet. ======================================= Trace Message: > inserting new mapping: ;uno[70945490];gcc3[70944768] Trace Message: > inserting new mapping: ;java[70944020];uno[70945490] Trace Message: > inserting new mapping: ;java[70944020];gcc3[70944768] An unexpected exception has been detected in native code outside the VM. Unexpected Signal : 10 occurred at PC=0x70988620 Function=(null)+0x70988620 Library=/home/jim/680/o2_src/solver/680/unxlngs.pro/lib/javaloader.uno.so
sb->sparcmoz: Lets start with your first problem of today, ./testcppu > sizeof(AlignSize_Impl) = 16 [...] Segmentation fault That is definitely not ok. First, I made a last minute fix to cppu (cppu/source/typelib/typelib.cxx 1.19.16.4, cppu/inc/typelib/typedescription.h 1.12.72.2). Please try it out. Second, to be extra sure, the list of relevant modules with modifications on sb10 is (in no particular order): registry, codemaker, idlc, stoc, offapi, cppu, unoil, bridges, testtools, jurt, udkapi, ridljar, cppuhelper. Did you update/build all of these? Third, do you have a plain SRC680m20 on which you could re-check whether the segfault is indeed introduced by our changes? That you get a bus error when executing the multinherit tests most probably indicates that something is still wrong with the bridges/cpp_uno changes, but it is unclear to me whether that might be related to the above segfault.
I will remove sb from the cc while I am organising things. Now getting ready to build, here is some dev@porting advice from sb: I do not understand exactly what your problem above is, but, anyway, I hope the following is of help to you: First, the current bridges/source/cpp_uno/gcc3_linux_sparc/cpp2uno.cxx 1.2 includes a "lie:" MediateClassData::createVTable says it generates snippet code that jumps to cpp_vtable_call via %l0: sethi $hi( cpp_vtable_call ), %l0 or %l0, %lo( cpp_vtable_call ), %l0 jmp %l0 but the generated snippet code *codeSnip++ = 0x15000000 | ...; *codeSnip++ = 0x9412a000 | ...; *codeSnip++ = 0x81c28000; reveal that the jump is actually made via %o2 instead: sethi %hi(cpp_vtable_call), %o2 or %o2, %lo(cpp_vtable_call), %o2 jmp %o2 The code in cpp_vtable_call includes instructions to restore the registers clobbered in the snippet code (%o0--2, now %i0--2, due to a register window shift at the start of cpp_vtable_call): ld [%fp+68], %i0 ld [%fp+72], %i1 ld [%fp+76], %i2 I think this code is not necessary, as cpp_vtable_call itself does not use any incoming parameters (it is declared void), and the incoming parameter registers %i0--5 need not be preserved across a function call (at least per the "System V Application Binary Interface: SPARC(R) Processor Supplement," Third Edition, p. 3-9; I think SPARC Linux also uses this ABI). To modify cpp2uno.cxx, the snippet code generation should be changed to: unsigned long * codeSnip; sal_Int32 functionIndex; sal_Int32 vtableOffset; // st %o0, [%sp+68]: *codeSnip++ = 0xd023a044; // st %o1, [%sp+72]: *codeSnip++ = 0xd223a048; // st %o2, [%sp+76]: *codeSnip++ = 0xd423a04c; // st %o3, [%sp+80]: *codeSnip++ = 0xd623a050; // st %o4, [%sp+84]: *codeSnip++ = 0xd823a054; // st %o5, [%sp+88]: *codeSnip++ = 0xda23a058; // sethi %hi(functionIndex), %o0: *codeSnip++ = 0x11000000 | (static_cast< unsigned long >(functionIndex) >> 10); // or %o0, %lo(functionIndex), %o0: *codeSnip++ = 0x90122000 | (static_cast< unsigned long >(functionIndex) & 0x3FF); // sethi %hi(vtableOffset), %o2: *codeSnip++ = 0x15000000 | (static_cast< unsigned long >(vtableOffset) >> 10); // or %o2, %lo(vtableOffset), %o2: *codeSnip++ = 0x9412a000 | (static_cast< unsigned long >(vtableOffset) & 0x3FF); // sethi %hi(cpp_vtable_call), %o3: *codeSnip++ = 0x17000000 | (((unsigned long) cpp_vtable_call) >> 10); // or %o3, %lo(cpp_vtable_call), %o3: *codeSnip++ = 0x9612e000 | (((unsigned long) cpp_vtable_call) & 0x3FF); // jmp %o3: *codeSnip++ = 0x81c2c000; // mov %sp, %o1: *codeSnip++ = 0x9210000e; which, as before, transports functionIndex (aka nTableEntry) in %o0 and the stack pointer in %o1, and, additionally, transports vtableOffset in %o2, and now clobbers %o3 (instead of %o2). Thus, the code in cpp_vtable_call has to be modified as follows: int functionIndex; void** pCallStack; int vtableOffset; __asm__( "st %%i0, %0\n\t" "st %%i1, %1\n\t" "st %%i2, %2\n\t" : : "m"(functionIndex), "m"(pCallStack), "m"(vtableOffset) ); As explained above, the additional code to restore any clobberd registers should not be necessary, but if you do not trust me :) that code would change to: "ld [%%fp+68], %%i0\n\t" "ld [%%fp+72], %%i1\n\t" "ld [%%fp+76], %%i2\n\t" "ld [%%fp+80], %%i3\n\t" Let me know whether this helps you, -Stephan
Jim Watson wrote: > OK, my only question now (i hope) is about class MediateClassData > > in linux intel it seems everything related to that class is gone - do i need > do that too? Yes, your cppu_cppInterfaceProxy_patchVtable and MediateClassData have to be replaced with the three new functions bridges::cpp_uno::shared::VtableFactory::mapBlockToVtable bridges::cpp_uno::shared::VtableFactory::createBlock bridges::cpp_uno::shared::VtableFactory::addLocalFunctions see bridges/inc/bridges/cpp_uno/shared/vtablefactory.hxx 1.1.2.2 for documentation on them.
> Now i have a question about nRegReturn which is referenced many times, in > that cpp_vtable_call() > > should i try and replicate the linux intel treatment in the following switch > statement > > switch( aType ) > { > case typelib_TypeClass_BOOLEAN: > etc etc > > ?? Hi Jim. You don't need to change anything in the switch block---it should continue to work fine, just as it did until now.
Progress report: bridges are working and testcppu OK at issue 24059. Now I have got the cws_src680_sb10 into my SRC680_m23, added the patches from issue 24059 and made further changes for multi-inheritance outlined above. Bridges has build OK so next step is some debugging to be done. bridges/source/cpp_uno/shared had to be built by hand, was not built by prj.lst Attachments are: (a) patches to bridges (not working yet) (b) patches for cppu tests (c) stack trace from testcppu (d) current versions of cpp2uno and uno2cpp
Created attachment 13123 [details] diff to build brdges with multi-inherit for m23
Created attachment 13124 [details] cppu test patches
Created attachment 13125 [details] testcppu results
Created attachment 13126 [details] cpp2uno complete file
Created attachment 13127 [details] uno2cpp complete file
bridges multi-inherit test results ================================== jim@sun:~/680/0225/bridges/unxlngs.pro/bin$ ./testmultinherit-java-server & [1] 31397 jim@sun:~/680/0225/bridges/unxlngs.pro/bin$ Server: Accepting... jim@sun:~/680/0225/bridges/unxlngs.pro/bin$ ./testmultinherit-java-client Server: ...connected... Server: ...bridged. waiting for gc Client and server both cleanly terminate now: Success [1]+ Done ./testmultinherit-java-server jim@sun:~/680/0225/bridges/unxlngs.pro/bin$ ./testmultinherit-native-server & [1] 31453 jim@sun:~/680/0225/bridges/unxlngs.pro/bin$ > accepting socket,host=localhost,port=2002... jim@sun:~/680/0225/bridges/unxlngs.pro/bin$ ./testmultinherit-native-client connection established../testmultinherit-native-client: line 1: 31468 Bus error uno -c com.sun.star.test.bridges.testmultinherit.impl -l testmultinherit.uno.so -ro test_javauno_multinherit.rdb -- "uno:socket,host=localhost,port=2002;urp;test" jim@sun:~/680/0225/bridges/unxlngs.pro/bin$ [1]+ Done ./testmultinherit-native-server
(gdb) run Starting program: /home/jim/680/0225/solver/680/unxlngs.pro/bin/uno -c com.sun.star.test.bridges.testmultinherit.impl -l testmultinherit.uno.so -ro test_javauno_multinherit.rdb -- uno:socket,host=localhost,port=2002\;urp\;test [New Thread 16384 (LWP 24149)] connection established.[New Thread 32769 (LWP 24922)] [New Thread 16386 (LWP 24956)] [New Thread 32771 (LWP 24998)] Program received signal SIGBUS, Bus error. [Switching to Thread 16384 (LWP 24149)] 0x70d37874 in com::sun::star::uno::Reference<com::sun::star::uno::XInterface>::set(com::sun::star::uno::XInterface*) (this=0xefffd658, pInterface=0x71db6174) at Reference.hxx:232 232 pInterface->acquire(); Current language: auto; currently c++ (gdb) where #0 0x70d37874 in com::sun::star::uno::Reference<com::sun::star::uno::XInterface>::set(com::sun::star::uno::XInterface*) (this=0xefffd658, pInterface=0x71db6174) at Reference.hxx:232 #1 0x70d362bc in com::sun::star::uno::Reference<com::sun::star::uno::XInterface>::operator=(com::sun::star::uno::Reference<com::sun::star::uno::XInterface> const&) (this=0xefffd658, rRef=@0xefffd568) at Reference.hxx:340 #2 0x70d34da0 in remotebridges_bridge::ORemoteBridge::getInstance(rtl::OUString const&) (this=0x70c8c638, sInstanceName=@0xefffd690) at /home/jim/680/0225/remotebridges/source/bridge/remote_bridge.cxx:304 #3 0x70c9b6dc in unourl_resolver::ResolverImpl::resolve(rtl::OUString const&) (this=0x70c87770, rUnoUrl=@0x706abc78) at /home/jim/680/0225/remotebridges/source/unourl_resolver/unourl_resolver.cxx:236 #4 0x70c6af80 in (anonymous namespace)::Service::run(com::sun::star::uno::Sequence<rtl::OUString> const&) () from ../lib/testmultinherit.uno.so #5 0x0002258c in main () #6 0x7055cdac in __libc_start_main () from /lib/libc.so.6 (gdb) Now to find Reference, also gdb <-- testcppu
Trace Message: > inserting new mapping: ;uno[707614a8];gcc3[7076aa58] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 1211)] 0x8197ecf4 in ?? () (gdb) where #0 0x8197ecf4 in ?? () #1 0x0003e22c in perform_test (xObj=@0xefffdb40, xDummy=@0xefffdb60) at /home/jim/680/0225/cppu/test/test_di.cxx:676 #2 0x0003e790 in test_CppBridge() () at /home/jim/680/0225/cppu/test/test_di.cxx:747 #3 0x0002a450 in main (argc=1, argv=0xefffdca4) at /home/jim/680/0225/cppu/test/testcppu.cxx:1146 (gdb) more full output attached
Created attachment 13224 [details] more testcppu results
sparcmoz --> sb: i dont know any more what to do, if you have any advice or instructions that would be appreciated.
Created attachment 13318 [details] fixed cpp2uno.cxx codeSnippet function
sb->sparcmoz: I spotted a bug in function codeSnippet in cpp2uno.cxx. Please try the attached version.
Are lines 298 & 302 correct in my cpp2uno.cxx? pThis = pCallStack[1]; pThis = pCallStack[0]; //jw: from solaris/sparc, linux/intel has [2] & [1] testcppu output. Starting program: /home/jim/680/0225/cppu/unxlngs.pro/bin/testcppu [New Thread 16384 (LWP 8795)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 8795)] 0x70723960 in cpp_mediate (nFunctionIndex=0, pCallStack=0xefffd61c, nVtableOffset=0, pRegisterReturn=0xefffd5b8) at /home/jim/680/0225/bridges/source/cpp_uno/gcc3_linux_sparc/cpp2uno.cxx:309 309 OSL_ENSURE( nFunctionIndex < pTypeDescr->nMapFunctionIndexToMemberIndex, (gdb) where #0 0x70723960 in cpp_mediate (nFunctionIndex=0, pCallStack=0xefffd61c, nVtableOffset=0, pRegisterReturn=0xefffd5b8) at /home/jim/680/0225/bridges/source/cpp_uno/gcc3_linux_sparc/cpp2uno.cxx:309 #1 0x707241cc in cpp_vtable_call () at /home/jim/680/0225/bridges/source/cpp_uno/gcc3_linux_sparc/cpp2uno.cxx:439 #2 0x0003e370 in checkInvalidInterfaceQuery (xObj=@0x706c446c) at /home/jim/680/0225/cppu/test/test_di.cxx:653 (gdb)
Created attachment 13326 [details] revised cpp2uno
new from building setup2 vnd.sun.star.expand:\$UNO_JAVA_COMPPATH/java_uno_accessbridge.jar Assertion Failed: File /home/jim/680/0225/bridges/source/cpp_uno/gcc3_linux_sparc/cpp2uno.cxx, Line 310: ### illegal vtable index!
at line 310: printf("nFunctionIndex= %x, pTypeDescr->nMapFunctionIndexToMemberIndex=%x\n", nFunctionIndex,pTypeDescr->nMapFunctionIndexToMemberIndex); OSL_ENSURE( nFunctionIndex < pTypeDescr->nMapFunctionIndexToMemberIndex, "### illegal vtable index!" ); -c vnd.sun.star.expand:\$UNO_JAVA_COMPPATH/java_uno_accessbridge.jar nFunctionIndex= 1, pTypeDescr->nMapFunctionIndexToMemberIndex=5 nFunctionIndex= 1, pTypeDescr->nMapFunctionIndexToMemberIndex=5 nFunctionIndex= 2, pTypeDescr->nMapFunctionIndexToMemberIndex=5 nFunctionIndex= 0, pTypeDescr->nMapFunctionIndexToMemberIndex=0 An unexpected exception has been detected in native code outside the VM.
Created attachment 13346 [details] most recent diff against entire CVS source
With some tracing I find the problem occurs here: ================= typelib_InterfaceTypeDescription * pTypeDescr = pCppI->getTypeDescr(); printf("got that pTypeDescr * OK\n"); sal_Int32 anIndex = 0; printf("try anIndex\n"); anIndex = pTypeDescr->nMapFunctionIndexToMemberIndex; printf("did that anIndex\n"); OSL_ENSURE( nFunctionIndex < pTypeDescr->nMapFunctionIndexToMemberIndex, "### illegal vtable index!" ); if (nFunctionIndex >= pTypeDescr->nMapFunctionIndexToMemberIndex) So that when cpp_mediate is called the first time then nFunctionIndex has value 0x80000000 which is changed to value 0. Results from testcppu: ====================== in codesnippet functionIndex=1, vtableOffset=0,simpleRetType=1 third caller in codesnippet functionIndex=2, vtableOffset=0,simpleRetType=1 Before functionIndex=80000000, pCallStack=efffe798, vtableOffset=0, nRegReturn=707241a4 bComplex=1 call cpp_mediate with functionIndex=80000000, pCallStack+17=efffe798, vtableOffset=0, (sal_Int64*)&nRegReturn=efffe778 In cpp_mediate nFunctionIndex=80000000 got that pTypeDescr * OK try anIndex Segmentation fault jim@sun:~/680/0225/cppu/unxlngs.pro/bin$ gdb output: ========== in codesnippet functionIndex=2, vtableOffset=0,simpleRetType=1 Before functionIndex=80000000, pCallStack=efffe6e8, vtableOffset=0, nRegReturn=707241a4 bComplex=1 call cpp_mediate with functionIndex=80000000, pCallStack+17=efffe6e8, vtableOffset=0, (sal_Int64*)&nRegReturn=efffe6c8 In cpp_mediate nFunctionIndex=80000000 got that pTypeDescr * OK try anIndex Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 4756)] 0x70723a34 in (anonymous namespace)::cpp_mediate(unsigned long, void**, long, long long*) () at guardedarray.hxx:68 68 public: (gdb) where #0 0x70723a34 in (anonymous namespace)::cpp_mediate(unsigned long, void**, long, long long*) () at guardedarray.hxx:68 #1 0x7072426c in (anonymous namespace)::cpp_vtable_call() () at guardedarray.hxx:68 #2 0x0003e370 in checkInvalidInterfaceQuery (xObj=@0x706c446c) at /home/jim/680/0225/cppu/test/test_di.cxx:653
This is my diary for tracking work, no action required. Some new diffs because the cpp2uno.cxx has been cleaned up and checked to solaris sparc. There is still a segfault in testcppu, at test_di.cxx in CheckInvalidInterfaceQuery where Any aRet( xObj->queryInterface( ::getCppuType((const lang::IllegalArgumentException *)0 ) ) ); problem is with queryInterface. multi-inherit java tests are OK but not native & testcppu fails. Next steps: commit these patches when next porting branch opens.
Created attachment 13596 [details] long long wrapper
Created attachment 13597 [details] cleaned up bridges
sb->sparcmoz: I think cpp_mediate (cpp2uno.cxx) is broken. Please try the following: ... // pCallStack: this, params // eventual [ret*] lies at pCallStack -1 // so count down pCallStack by one to keep it simple bridges::cpp_uno::shared::CppInterfaceProxy * pCppI = bridges::cpp_uno::shared::CppInterfaceProxy::castInterfaceToProxy( static_cast< char * >(*pCallStack) - nVtableOffset); if ((nFunctionIndex & 0x80000000) != 0) { nFunctionIndex &= 0x7FFFFFFF; --pCallStack; } typelib_InterfaceTypeDescription * pTypeDescr = pCppI->getTypeDesr(); ...
sparcmoz-->sb: I did that change to cpp_mediate. jim@sun:~/680/cppu/unxlngs.pro/bin$ ./testcppu > sizeof(AlignSize_Impl) = 16 > sizeof(M) = 8 > sizeof(N) = 12 > sizeof(N2) = 12 > sizeof(O) = 16 > sizeof(D) = 8 > sizeof(C1) = 2 > sizeof(C2) = 8 > sizeof(C3) = 24 > sizeof(C4) = 40 > sizeof(C5) = 56 > sizeof(C6) = 72 > sizeof(O2) = 24 > sizeof(Char3) = 3 > sizeof(P) = 24 > sizeof(second) = 4 Trace Message: > inserting new mapping: ;uno[706e8cf8];gcc3[706e8628] Trace Message: > revoking mapping ;uno[706e8cf8];gcc3[706e8628] Trace Message: > inserting new mapping: ;uno[706e8628];gcc3[706e9498] Trace Message: > revoking mapping ;uno[706e8628];gcc3[706e9498] Trace Message: > inserting new mapping: ;gcc3[706f05a0];uno[706e9498] Trace Message: > inserting new mapping: ;uno[706e9498];gcc3[706f2a48] Segmentation fault jim@sun:~/680/cppu/unxlngs.pro/bin$ From gdb: Trace Message: > inserting new mapping: ;uno[706e9498];gcc3[706f2a48] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 9177)] 0x00000000 in ?? () (gdb) where #0 0x00000000 in ?? () (gdb) list 1118 pTypeRef = NULL; 1119 } 1120 1121 /* 1122 * main. 1123 */ 1124 int SAL_CALL main(int argc, char **argv) 1125 { 1126 { 1127 typelib_setCacheSize( 200 ); (gdb) I dont know if this is valid, but if I comment out that last statement //typelib_setCacheSize( 200 ); then i get this from gdb: Trace Message: > inserting new mapping: ;uno[706e9488];gcc3[706f2a48] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 10843)] 0x00000000 in ?? () (gdb) where #0 0x00000000 in ?? () (gdb) list 1125 { 1126 { 1127 // typelib_setCacheSize( 200 ); 1128 #ifdef SAL_W32 1129 Reference< registry::XSimpleRegistry > xRegistry( ::cppu::createSimpleRegistry() ); 1130 xRegistry->open( OUString( RTL_CONSTASCII_USTRINGPARAM("testcppu.rdb") ), sal_True, sal_False ); 1131 Reference< XComponentContext > xContext( 1132 ::cppu::bootstrap_InitialComponentContext( xRegistry ) ); 1133 #endif 1134 testEnvironments(); (gdb) I got some comments on that (gdb) where #0 0x00000000 in ?? () Duncan Roe duncan_roe at acslink.net.au Mon Mar 8 04:15:56 GMT 2004 * Previous message: [clug] gdb output * Next message: [clug] PCI 2.2 devices and a non-PCI 2.2 bus * Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] Hi Jim, Gdb is telling you that the thread is executing at location zero, and that there is no stack history available because the stack pointer is also zero. In general, there are only three ways to make the program counter do something other than move on to the next instruction in sequence: jump, call, and return. With the displayed symptoms, I would say the most likely candidate of the above 3 is return. So, you are looking for a function that wrote zeroes over its stack frame and then tried to return, setting both the program counter and stack frame pointer to zero. The function that did the zeroising is not necessarily at fault: you can call memset to produce the exact scenario for instance:- int main(int argc,char**argv) { int i; memset(&i,0,16); return 0; } will fail when run under gdb:- Program received signal SIGSEGV, Segmentation fault. 0x00000000 in ?? () (gdb) bt #0 0x00000000 in ?? () (gdb) It wrote 12 bytes beyond the end of "i" and zapped the stack. I suspect thread 16384 is your initial thread (but I'm not sure). Perhaps "info threads" will tell you. Anyway, you could try "n"ext through your toplevel until you find the function call containing the problem. Then breakpoint that function and repeat the process. Or maybe if you just audit you memset calls you'll find the problem. Cheers ... Duncan. On Fri, Mar 05, 2004 at 08:44:09PM +1100, Jim Watson wrote: > how would i interpret this output from gdb? > m received signal SIGSEGV, Segmentation fault. > [Switching to Thread 16384 (LWP 17669)] > 0x00000000 in ?? () > (gdb) where > #0 0x00000000 in ?? () > (gdb) > > jim
Created attachment 13828 [details] revised cpp_mediate
I have committed the platform specific code into cvs cws_src680_ooo20040329, but as mentioned above there is some debugging still required. The current status of the build is that regcomp fails java_uno_accessbridge.jar in setup2. I workaround this so the installer installs the product which runs to display the splashscreen but crashes . Both problems apparently due to bridges ./soffice& <snip> > sizeof(second) = 4 Trace Message: > inserting new mapping: ;uno[747be298];gcc3[747be988] sh: line 1: /home/jim/680/solver/680/unxlngs.pro/bin/crash_report: Permission denied Fatal exception: Signal 11 Stack: /home/jim/OpenOffice.org680/program/libsal.so.3+0x26264[0x70c8a264] /home/jim/OpenOffice.org680/program/libsal.so.3+0x26374[0x70c8a374] /lib/libpthread.so.0+0xa898[0x712b6898] /lib/libc.so.6+0x32f24[0x71562f24] /home/jim/OpenOffice.org680/program/libgcc3_uno.so+0x80e0[0x7482c0e0] /home/jim/OpenOffice.org680/program/libcppuhelpergcc3.so.3+0x25ee0(_ZN4cppu14throwExceptionERKN3com3sun4star3uno3AnyE+0x244)[0x70bb5ee0] So, back to the degugging again...
Here is my latest diff against cws_src680_ooo20040329, thees patches are already in sb15 for flush/vtable.
Created attachment 13901 [details] patches pending in sb15
single steps (next) 743 (*pUnoI->release)( pUnoI ); (gdb) 744 (*pCppEnv->release)( pCppEnv ); (gdb) 745 (*pUnoEnv->release)( pUnoEnv ); (gdb) 748 if (perform_test( xMapped, xDummy )) (gdb) Breakpoint 2, perform_test (xObj=@0xefffe480, xDummy=@0xefffe4a0) at /home/jim/680/cppu/test/test_di.cxx:677 677 checkInvalidInterfaceQuery( xObj ); (gdb) Breakpoint 3, checkInvalidInterfaceQuery (xObj=@0xefffe480) at /home/jim/680/cppu/test/test_di.cxx:654 654 Any aRet( xObj->queryInterface( ::getCppuType( ( const lang::IllegalArgumentException *)0 ) ) ); (gdb) Program received signal SIGSEGV, Segmentation fault. 0x00000000 in ?? () (gdb) ./testcppu > sizeof(second) = 4 osl_getsymbol: got Symbol uno_initEnvironment osl_getsymbol: got Symbol component_canUnload osl_loadModule: cannot load module libtest_gcc3_gcc3.so for reason: ./libtest_gcc3_gcc3.so: cannot open shared object file: No such file or directory osl_getsymbol: got Symbol uno_ext_getMapping osl_loadModule: cannot load module libtest_uno_uno.so for reason: ./libtest_uno_uno.so: cannot open shared object file: No such file or directory osl_getsymbol: got Symbol uno_initEnvironment osl_getsymbol: got Symbol uno_ext_getMapping q3 Assertion Failed: File /home/jim/680/cppuhelper/source/implbase_ex.cxx, Line 114: querying for interface "com.sun.star.lang.IllegalArgumentException": no interface type! Backtrace: [0] /home/jim/680/solver/680/unxlngs.pro/lib/libcppuhelpergcc3.so.3: ???+0x518c0 Backtrace: [1] /home/jim/680/solver/680/unxlngs.pro/lib/libcppuhelpergcc3.so.3: _ZN4cppu20WeakImplHelper_queryERKN3com3sun4star3uno4TypeEPNS_10class_dataEPvPNS_11OWeakObjectE+0x44 Backtrace: [2] ./testcppu: _ZN4cppu15WeakImplHelper1IN4test20XLanguageBindingTestEE14queryInterfaceERKN3com3sun4star3uno4TypeE+0x28 Backtrace: [3] ./testcppu: ???+0x2e020 Backtrace: [4] ./testcppu: _Z14test_CppBridgev+0x150 Backtrace: [5] ./testcppu: main+0x40 Backtrace: [6] /lib/libc.so.6: __libc_start_main+0xf0 Backtrace: [7] ./testcppu: _start+0x2c q3 osl_getsymbol: got Symbol uno_initEnvironment osl_getsymbol: got Symbol component_canUnload osl_getsymbol: got Symbol uno_ext_getMapping q3 osl_getsymbol: got Symbol uno_initEnvironment osl_getsymbol: got Symbol uno_ext_getMapping Segmentation fault jim@sun:~/680/cppu/unxlngs.pro/bin$ the q3 is in cppuhelper/source//implbase_ex.cxx approx lines 378 / WeakImplHelper //================================================================================================== Any SAL_CALL WeakImplHelper_query( Type const & rType, class_data * cd, void * that, OWeakObject * pBase ) SAL_THROW( (RuntimeException) ) { printf("q3 \n"); checkInterface( rType ); typelib_TypeDescriptionReference * pTDR = rType.getTypeLibType();
Created attachment 14022 [details] cppuhelper traces diff
From running ./soffice a different backtrace from sal/osl/backtrace.c this time Trace Message: ### ignoring context calling OSingleFactoryHelper::createInstanceEveryTime()! q3 q3 q3 q3 Fatal exception: Signal 11 Stack: /home/jim/OpenOffice.org680/program/libsal.so.3+0x39934[0x70ccd934] /home/jim/OpenOffice.org680/program/libsal.so.3+0x39b2c[0x70ccdb2c] /lib/libpthread.so.0+0xa898[0x71322898] /lib/libc.so.6+0x32f24[0x715cef24] /home/jim/OpenOffice.org680/program/libgcc3_uno.so+0x52e0[0x73d3d2e0] /home/jim/OpenOffice.org680/program/libcppuhelpergcc3.so.3+0x40da0(_ZN4cppu14throwExceptionERKN3com3sun4star3uno3AnyE+0x394)[0x70bd4da0] /home/jim/OpenOffice.org680/program/libucbhelper3gcc3.so+0x7c554(_ZN9ucbhelper22cancelCommandExecutionEN3com3sun4star3ucb11IOErrorCodeERKNS2_3uno8SequenceINS5_3AnyEEERKNS5_9ReferenceINS3_19XCommandEnvironmentEEERKN3rtl8OUStringERKNSB_INS3_17XCommandProcessorEEE+0x2c0)[0x70b38554] /home/jim/OpenOffice.org680/program/libucpfile1.so+0x51900[0x73d15900] /home/jim/OpenOffice.org680/program/libucpfile1.so+0x3287c[0x73cf687c] /home/jim/OpenOffice.org680/program/libucpfile1.so+0x18124[0x73cdc124] /home/jim/OpenOffice.org680/program/libucpfile1.so+0x13370[0x73cd7370] /home/jim/OpenOffice.org680/program/libucbhelper3gcc3.so+0x37e00(_ZN3ucb12Content_Impl14executeCommandERKN3com3sun4star3ucb7CommandE+0x84)[0x70af3e00] /home/jim/OpenOffice.org680/program/libucbhelper3gcc3.so+0x309b8(_ZN3ucb7Content14executeCommandERKN3rtl8OUStringERKN3com3sun4star3uno3AnyE+0x94)[0x70aec9b8] /home/jim/OpenOffice.org680/program/libutl680ls.so+0x6ebdc(_ZN3utl16UCBContentHelper4KillERK6String+0x178)[0x70902bdc] /home/jim/OpenOffice.org680/program/soffice.bin+0x2d63c(_ZN7desktop7Desktop24CreateTemporaryDirectoryEv+0x118)[0x3d63c] /home/jim/OpenOffice.org680/program/soffice.bin+0x2c980(_ZN7desktop7Desktop16RegisterServicesERN3com3sun4star3uno9ReferenceINS3_4lang20XMultiServiceFactoryEEE+0x3b0)[0x3c980] /home/jim/OpenOffice.org680/program/soffice.bin+0x1d7dc(_ZN7desktop7Desktop4MainEv+0x704)[0x2d7dc] /home/jim/OpenOffice.org680/program/libvcl680ls.so+0xaa3fc(_Z6SVMainv+0x4c)[0x700d63fc] /home/jim/OpenOffice.org680/program/libvcl680ls.so+0x23a5c0(main+0x30)[0x702665c0] /lib/libc.so.6+0x1cda4(__libc_start_main+0xf0)[0x715b8da4] /home/jim/OpenOffice.org680/program/soffice.bin+0x18358(_start+0x2c)[0x28358]
I need file this email where i can find it later, as it is another helper bazik@gentoo.org
closonigng -= please open a new issue for post-ooo20040329 tracking of sparc bridge issues