Re: Cppuno in bridges, HELP needed.

2018-03-06 Thread Jan Iversen 


> On 6 Mar 2018, at 14:17, Stephan Bergmann  wrote:
> 
> On 06.03.2018 11:38, Jan Iversen wrote:
>> At some point a piece of code (in the same executable) decides to make a uno 
>> call, this looks like
>> Cpp2uno_call() ->
>>  raise_exception()
>>  __cxa_throw() ->
>>  ( C++ throw handling) ->
>>  getCaughtException() ->
>>  UnoInterfaceProxyDispatch() ->
>>  cpp_call() ->
>>  CallVirtualMethod() ->
>>  ( Call requested 
>> function )
> 
> Hard to tell what you're actually looking at without seeing a real backtrace 
> (e.g., I have no idea what "Cpp2uno_call()" is supposed to mean).

No problem, I just tried to limit the mail size :-) cpp2uno_call is a function 
implemented in bridges/source/cppuno/gcc*

Backtrace:

(lldb) bt
* thread #10, name = 'LOKitThread.queue', stop reason = breakpoint 14.1
  * frame #0: 0x00010cb6b416 
libKit.dylib`gcc3::callVirtualMethod(pThis=0x0001173b0f20, nVtableIndex=4, 
pRegisterReturn=0x, pReturnTypeRef=0x60898830, 
bSimpleReturn=true, pStack=0x72a04dd0, nStack=0, 
pGPR=0x72a050e0, pFPR=0x72a050a0) at callvirtualmethod.cxx:73
frame #1: 0x00010cb6a48f 
libKit.dylib`cpp_call(pThis=0x604000e76c40, aVtableSlot=(offset = 0, index 
= 4), pReturnTypeRef=0x60898830, nParams=0, pParams=0x, 
pUnoReturn=0x, pUnoArgs=0x, 
ppUnoExc=0x72a053f0) at uno2cpp.cxx:233
frame #2: 0x00010cb69bee 
libKit.dylib`unoInterfaceProxyDispatch(pUnoI=0x604000e76c40, 
pMemberDescr=0x60c00015bcd0, pReturn=0x, 
pArgs=0x, ppException=0x72a053f0) at uno2cpp.cxx:418
frame #3: 0x0001133528cd 
libKit.dylib`com::sun::star::uno::UnoInterfaceReference::dispatch(this=0x72a05418,
 pMemberType=0x60c00015bcd0, pReturn=0x, 
pArgs=0x, ppException=0x72a053f0) const at 
dispatcher.hxx:173
frame #4: 0x000113352558 libKit.dylib`cppu::getCaughtException() at 
exc_thrower.cxx:238
frame #5: 0x00011371d85f 
libKit.dylib`utl::UCBContentHelper::IsDocument(url=0x72a059e0) at 
ucbhelper.cxx:150
frame #6: 0x00010c83d005 
libKit.dylib`FSStorageFactory::createInstanceWithArguments(this=0x61a6b300,
 aArguments=0x72a05b40) at fsfactory.cxx:128
frame #7: 0x00010c83d883 libKit.dylib`non-virtual thunk to 
FSStorageFactory::createInstanceWithArguments(this=0x61a6b300, 
aArguments=0x72a05b40) at fsfactory.cxx:0
frame #8: 0x00010c917d91 
libKit.dylib`framework::PresetHandler::getOrCreateRootStorageShare(this=0x601f2500)
 at presethandler.cxx:226
frame #9: 0x00010c918d52 
libKit.dylib`framework::PresetHandler::connectToResource(this=0x601f2500,
 eConfigType=E_MODULES, sResource=0x72a06740, 
sModule=0x7fb0704781a0, xDocumentRoot=0x72a06738, 
rLanguageTag=0x72a067a0) at presethandler.cxx:349
frame #10: 0x00010cab7a6c libKit.dylib`(anonymous 
namespace)::ModuleUIConfigurationManager::ModuleUIConfigurationManager(this=0x7fb0704780a0,
 xContext=0x72a06890, aArguments=0x72a06de0) at 
moduleuiconfigurationmanager.cxx:888
frame #11: 0x00010cab6dd5 libKit.dylib`(anonymous 
namespace)::ModuleUIConfigurationManager::ModuleUIConfigurationManager(this=0x7fb0704780a0,
 xContext=0x72a06890, aArguments=0x72a06de0) at 
moduleuiconfigurationmanager.cxx:855
frame #12: 0x00010cab6cba 
libKit.dylib`::com_sun_star_comp_framework_ModuleUIConfigurationManager_get_implementation(context=0x60800012af00,
 arguments=0x72a06de0) at moduleuiconfigurationmanager.cxx:1676
frame #13: 0x0001133c55a0 libKit.dylib`com::sun::star::uno::XInterface* 
std::__1::__invoke_void_return_wrapper::__call const&), 
com::sun::star::uno::XComponentContext*, 
com::sun::star::uno::Sequence 
const&>(com::sun::star::uno::XInterface* 
(*&&&)(com::sun::star::uno::XComponentContext*, 
com::sun::star::uno::Sequence const&), 
com::sun::star::uno::XComponentContext*&&, 
com::sun::star::uno::Sequence const&&&) [inlined] 
decltype(__f=0x600f6998, __args=0x72a069c0, 
__args=0x72a06de0)(com::sun::star::uno::XComponentContext*, 
com::sun::star::uno::Sequence 
const&)>(fp)(std::__1::forward const&>(fp0))) 
std::__1::__invoke const&), 
com::sun::star::uno::XComponentContext*, 
com::sun::star::uno::Sequence 
const&>(com::sun::star::uno::XInterface* 
(*&&&)(com::sun::star::uno::XComponentContext*, 
com::sun::star::uno::Sequence const&), 
com::sun::star::uno::XComponentContext*&&, 
com::sun::star::uno::Sequence const&&&) at 
type_traits:4291
frame #14: 0x0001133c5574 libKit.dylib`com::sun::star::uno::XInterface* 
std::__1

Re: Cppuno in bridges, HELP needed.

2018-03-06 Thread Stephan Bergmann 

On 06.03.2018 11:38, Jan Iversen wrote:

At some point a piece of code (in the same executable) decides to make a uno 
call, this looks like

Cpp2uno_call() ->
raise_exception()
__cxa_throw() ->
( C++ throw handling) ->
getCaughtException() ->
UnoInterfaceProxyDispatch() ->
cpp_call() ->
CallVirtualMethod() ->
( Call requested 
function )


Hard to tell what you're actually looking at without seeing a real 
backtrace (e.g., I have no idea what "Cpp2uno_call()" is supposed to mean).


As there is "getCaughtException()" in your picture: 
cppu::getCaughtException (cppuhelper/exc_hlp.hxx) internally uses the 
bridge between C++ and binary UNO to translate the C++ exception being 
caught by the current catch block into a css::uno::Any.  You need that 
bridge in all its glory, beautiful assembler hackery and all, for that 
functionality to work.



Because on iOS, no external process will ever call the UNO interface, it is 1 
single executable (I also removed the pipes etc).


Just to be clear:  The bridge between C++ and binary UNO is used in more 
scenarios than just inter-process communication.  Other examples are 
bridging to code in other languages like Java, the thread-affine bridge 
used by some (Java) database code, or cppu::getCaughtException mentioned 
above.  While the former examples may not be relevant on iOS, the latter 
one certainly is.

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Cppuno in bridges, HELP needed.

2018-03-06 Thread Jan Iversen 
Hi.

I am still trying to get my head around understanding bridges, and how I can 
make it work for arm64/iOS.

At some point a piece of code (in the same executable) decides to make a uno 
call, this looks like

Cpp2uno_call() ->
raise_exception()
__cxa_throw() ->
( C++ throw handling) ->
getCaughtException() ->
UnoInterfaceProxyDispatch() ->
cpp_call() ->
CallVirtualMethod() ->
( Call requested 
function )

Now it all looks synchronous to me, and I right in assuming this all happens 
without any dispatch.

If my assumption is correct, I should be able to shortcut the whole lot and 
make a simple:
Cpp2uno_call() ->
( Call requested function )

Because on iOS, no external process will ever call the UNO interface, it is 1 
single executable (I also removed the pipes etc).

Can someone please tell me, if/where I am thinking totally wrong. My objective 
is to get rid of all the ugly assembler code.

Thanks in advance.
rgds
Jan I.


Ps. I had never expected the need to “expert” on the lower layers of LO, but 
after having been fighting SAL_TIMER, then threads and now cppuno, I think I am 
slowly understanding how the very low level of LO works. This might be a good 
thing when/if we do another port (or just want to optimise).


___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice