[Bug lto/50394] [meta-bug] Issues with building libreoffice with LTO

2011-09-21 Thread michael.meeks at suse dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50394

Michael Meeks  changed:

   What|Removed |Added

 CC||michael.meeks at suse dot
   ||com

--- Comment #20 from Michael Meeks  2011-09-21 
11:03:30 UTC ---
For:

terminate called after throwing an instance of
'com::sun::star::container::NoSuchElementException'
It throws an exception in: xmlreader::XmlReader::XmlReader(rtl::OUString
const&) () from image/usr/ure/lib/libxmlreader.so.
This happens in xmlreader/source/xmlreader.cxx.

This is new code, and shouldn't suffer lots of aliasing / compilation
nasties I hope - it is also -fairly- self-standing and relatively simple. If we
have a problem here - we have a real problem I think. I'd personally focus on
that, it should (I hope) be easier.

How did you install though ? run a 'make dev-install' ? and then run
install/program/soffice ? 

this:

#6  0x77d0d741 in __cxa_throw () from /usr/lib64/libstdc++.so.6
#7  0x718915c8 in gcc3::raiseException(_uno_Any*, _uno_Mapping*) ()
from
/var/tmp/portage/app-office/libreoffice--r1/image/usr/ure/lib/libgcc3_uno.so
#8  0x71892dff in
cpp2uno_call(bridges::cpp_uno::shared::CppInterfaceProxy*,
_typelib_TypeDescription const*, _typelib_TypeDescriptionReference*, int,
_typelib_MethodParameter*, void**, void**, void**, unsigned long*) () from
/var/tmp/portage/app-office/libreoffice--r1/image/usr/ure/lib/libgcc3_uno.so
#9  0x71893553 in cpp_vtable_call () from

is altogether more hairy - we create at run-time C++ vtables packed with
trampolines so we can intercept / model native C++ objects and interact with
them via python etc. that would need some more intense debugging love I guess.


[Bug lto/50394] [meta-bug] Issues with building libreoffice with LTO

2011-09-23 Thread michael.meeks at suse dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50394

--- Comment #24 from Michael Meeks  2011-09-23 
08:33:17 UTC ---
> I can imagine that this sort of magic breaks with LTO. Is the solution as 
> simple as using non-LTO version of libgcc3_uno.so? I will try to take a look 
> how this is implemented.

Great - so, we wouldn't loose much by having the bridge compiled without
optimisation - it is ultimately used to map C++ -> Java or python so all
performance is already shot by that stage ;-)

bridges/source/cpp_uno/gcc3_linux_intel/call.s
bridges/source/cpp_uno/gcc3_linux_x86-64/call.s

are the places to dig - unfortunately there is -far- too much cut/paste going
on in here, though we've done some work to try to share more IIRC.

These snippets are used by cpp2uno.cxx - to build trampolines cf. 'codeSnippet'
- which (I hope) should work fine, and by uno2cpp.cxx to invoke things eg.
'uno2cpp.cxx's callVirtualMethod - which has some fun assembler in each case.

Does that help ?