Building libreoffice with clang on ppc64

classic Classic list List threaded Threaded
5 messages Options
Piotr Kubaj Piotr Kubaj
Reply | Threaded
Open this post in threaded view
|

Building libreoffice with clang on ppc64

Hello,

I'm trying to build LibreOffice 6.3.2 on FreeBSD/powerpc64 with LLVM 9.0.0 (elfv2 ABI).

My problem is that I'm getting those errors https://pastebin.com/dKAY28ns

I tried to patch them with https://pastebin.com/66Xhi1D1 using similar code to x86-64. But then I'm getting a segfault at postcmd stage at the end of compilation.

LibreOffice builds just fine with GCC 9.2, but this is still on elfv1. FreeBSD/powerpc* switches to LLVM for elfv2.

--
To unsubscribe e-mail to: [hidden email]
Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette
List archive: https://listarchives.libreoffice.org/global/users/
Privacy Policy: https://www.documentfoundation.org/privacy
Piotr Kubaj Piotr Kubaj
Reply | Threaded
Open this post in threaded view
|

Re: Building libreoffice with clang on ppc64

Here's the backtrace. The process that segfaults is gengan.bin:
#0  0x000000081baea134 in (anonymous namespace)::cpp_mediate(unsigned long, void**, void**, long, long*)
    (nOffsetAndIndex=60434681040, gpreg=0x3ffffffffffef830, fpreg=0x3ffffffffffef7c8, sp=4611686018427320272, pRegisterReturn=0x3ffffffffffef7b8)
    at bridges/source/cpp_uno/gcc3_linux_powerpc64/cpp2uno.cxx:396
#1  0x000000081bae9f50 in privateSnippetExecutor() () at bridges/source/cpp_uno/gcc3_linux_powerpc64/cpp2uno.cxx:563
#2  0x00000008121de234 in cppu::throwException(com::sun::star::uno::Any const&)Python Exception <class 'gdb.error'> No type named 挀漀洀⸀猀甀渀⸀猀琀愀爀⸀甀挀戀⸀䤀渀琀攀爀愀挀琀椀瘀攀
䄀甀最洀攀渀琀攀搀䤀伀䔀砀挀攀瀀琀椀漀渀.:
 (exc=) at cppuhelper/source/exc_thrower.cxx:207
#3  0x000000081672ebd4 in ucbhelper::cancelCommandExecution(com::sun::star::ucb::IOErrorCode, com::sun::star::uno::Sequence<com::sun::star::uno::Any> const&, com::sun::star::uno::Reference<com::sun::star::ucb::XCommandEnvironment> const&, rtl::OUString const&, com::sun::star::uno::Reference<com::sun::star::ucb::XCommandProcessor> const&)
    (eError=com::sun::star::ucb::IOErrorCode::IOErrorCode_NOT_EXISTING, rArgs=
    uno::Sequence of length 2 = {...}, xEnv=empty uno::Reference, rMessage="an error occurred during file opening", xContext=uno::Reference to (fileaccess::BaseContent *) 0x81d0b5258) at ucbhelper/source/provider/cancelcommandexecution.cxx:109
#4  0x000000081d1ac3c0 in fileaccess::throw_handler(int, int, com::sun::star::uno::Reference<com::sun::star::ucb::XCommandEnvironment> const&, rtl::OUString const&, fileaccess::BaseContent*, bool)
    (errorCode=12, minorCode=2, xEnv=empty uno::Reference, aUncPath="file:///tmp/usr/ports/editors/libreoffice/work/libreoffice-6.3.2.2/workdir/Gallery/symbols/symbols", pContent=0x81d0b5220, isHandled=false) at ucb/source/ucp/file/filglob.cxx:362
#5  0x000000081d1eb260 in fileaccess::TaskManager::endTask(int, rtl::OUString const&, fileaccess::BaseContent*)
    (this=0x81c84bcc0, CommandId=11, aUncPath="file:///tmp/usr/ports/editors/libreoffice/work/libreoffice-6.3.2.2/workdir/Gallery/symbols/symbols", pContent=0x81d0b5220)
    at ucb/source/ucp/file/filtask.cxx:408
#6  0x000000081d18c1a8 in fileaccess::BaseContent::endTask(int) (this=0x81d0b5220, CommandId=11) at ucb/source/ucp/file/bc.cxx:1165
#7  0x000000081d189ad8 in fileaccess::BaseContent::execute(com::sun::star::ucb::Command const&, int, com::sun::star::uno::Reference<com::sun::star::ucb::XCommandEnvironment> const&)
    (this=0x81d0b5220, aCommand=..., CommandId=11, Environment=empty uno::Reference) at ucb/source/ucp/file/bc.cxx:382
#8  0x00000008166fa59c in ucbhelper::Content_Impl::executeCommand(com::sun::star::ucb::Command const&) (this=0x81c82ac00, rCommand=...) at ucbhelper/source/client/content.cxx:1254
#9  0x00000008166fb42c in ucbhelper::Content::getPropertyValuesInterface(com::sun::star::uno::Sequence<rtl::OUString> const&)
    (this=0x3fffffffffff0b78, rPropertyNames=uno::Sequence of length 1 = {...}) at ucbhelper/source/client/content.cxx:491
#10 0x00000008166faa28 in ucbhelper::Content::getPropertyValues(com::sun::star::uno::Sequence<rtl::OUString> const&)
    (this=0x3fffffffffff0b78, rPropertyNames=uno::Sequence of length 1 = {...}) at ucbhelper/source/client/content.cxx:450
#11 0x00000008166fa894 in ucbhelper::Content::getPropertyValue(rtl::OUString const&) (this=0x3fffffffffff0b78, rPropertyName="Title") at ucbhelper/source/client/content.cxx:429
#12 0x00000008141f6324 in FileExists(INetURLObject const&) (rURL=...) at svx/source/gallery2/galmisc.cxx:228
#13 0x00000008141e9f78 in GalleryThemeEntry::ImplGetURLIgnoreCase(INetURLObject const&) (rURL=...) at svx/source/gallery2/gallery1.cxx:204
#14 0x00000008141e97a0 in GalleryThemeEntry::GalleryThemeEntry(bool, INetURLObject const&, rtl::OUString const&, bool, bool, unsigned int, bool)
    (this=0x81cdfe800, bCreateUniqueURL=true, rBaseURL=..., rName="symbols", _bReadOnly=false, _bNewFile=true, _nId=0, _bThemeNameFromResource=false)
    at svx/source/gallery2/gallery1.cxx:131
#15 0x00000008141eca28 in Gallery::CreateTheme(rtl::OUString const&) (this=0x81bb80800, rThemeName="symbols") at svx/source/gallery2/gallery1.cxx:608
#16 0x00000000100119dc in createTheme(rtl::OUString const&, rtl::OUString const&, rtl::OUString const&, std::__1::vector<INetURLObject, std::__1::allocator<INetURLObject> >&, bool)
    (aThemeName="symbols", aGalleryURL="file:///tmp/usr/ports/editors/libreoffice/work/libreoffice-6.3.2.2/workdir/Gallery/symbols", aDestDir="file:///tmp/usr/ports/editors/libreoffice/work/libreoffice-6.3.2.2/extras/source/gallery", rFiles=std::vector of length 90 = {...}, bRelativeURLs=true) at svx/source/gengal/gengal.cxx:74
#17 0x000000001001115c in GalApp::Main() (this=0x10040048 <vclmain::createApplication()::aGalApp>) at svx/source/gengal/gengal.cxx:298
#18 0x00000008136b6208 in ImplSVMain() () at vcl/source/app/svmain.cxx:201
#19 0x00000008136b790c in SVMain() () at vcl/source/app/svmain.cxx:235
#20 0x0000000010024448 in sal_main() () at vcl/source/salmain/salmain.cxx:38
#21 0x00000000100243dc in main(int, char**) (argc=10, argv=0x3fffffffffff1b58) at vcl/source/salmain/salmain.cxx:32

On 19-10-21 21:38:29, Piotr Kubaj wrote:
> Hello,
>
> I'm trying to build LibreOffice 6.3.2 on FreeBSD/powerpc64 with LLVM 9.0.0 (elfv2 ABI).
>
> My problem is that I'm getting those errors https://pastebin.com/dKAY28ns
>
> I tried to patch them with https://pastebin.com/66Xhi1D1 using similar code to x86-64. But then I'm getting a segfault at postcmd stage at the end of compilation.
>
> LibreOffice builds just fine with GCC 9.2, but this is still on elfv1. FreeBSD/powerpc* switches to LLVM for elfv2.

Thanks,
Piotr Kubaj.

--
To unsubscribe e-mail to: [hidden email]
Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette
List archive: https://listarchives.libreoffice.org/global/users/
Privacy Policy: https://www.documentfoundation.org/privacy
sberg sberg
Reply | Threaded
Open this post in threaded view
|

Re: Building libreoffice with clang on ppc64

On 22/10/2019 18:28, Piotr Kubaj wrote:

> Here's the backtrace. The process that segfaults is gengan.bin:
> #0  0x000000081baea134 in (anonymous namespace)::cpp_mediate(unsigned long, void**, void**, long, long*)
>      (nOffsetAndIndex=60434681040, gpreg=0x3ffffffffffef830, fpreg=0x3ffffffffffef7c8, sp=4611686018427320272, pRegisterReturn=0x3ffffffffffef7b8)
>      at bridges/source/cpp_uno/gcc3_linux_powerpc64/cpp2uno.cxx:396
> #1  0x000000081bae9f50 in privateSnippetExecutor() () at bridges/source/cpp_uno/gcc3_linux_powerpc64/cpp2uno.cxx:563
> #2  0x00000008121de234 in cppu::throwException(com::sun::star::uno::Any const&)Python Exception <class 'gdb.error'> No type named 挀漀洀⸀猀甀渀⸀猀琀愀爀⸀甀挀戀⸀䤀渀琀攀爀愀挀琀椀瘀攀
> 䄀甀最洀攀渀琀攀搀䤀伀䔀砀挀攀瀀琀椀漀渀.:
>   (exc=) at cppuhelper/source/exc_thrower.cxx:207
> #3  0x000000081672ebd4 in ucbhelper::cancelCommandExecution(com::sun::star::ucb::IOErrorCode, com::sun::star::uno::Sequence<com::sun::star::uno::Any> const&, com::sun::star::uno::Reference<com::sun::star::ucb::XCommandEnvironment> const&, rtl::OUString const&, com::sun::star::uno::Reference<com::sun::star::ucb::XCommandProcessor> const&)
>      (eError=com::sun::star::ucb::IOErrorCode::IOErrorCode_NOT_EXISTING, rArgs=
>      uno::Sequence of length 2 = {...}, xEnv=empty uno::Reference, rMessage="an error occurred during file opening", xContext=uno::Reference to (fileaccess::BaseContent *) 0x81d0b5258) at ucbhelper/source/provider/cancelcommandexecution.cxx:109

So this smells like it is indeed related to the changes in your below
patch.  (The code is about synthesizing a C++ `throw some_exception`
expression, which may require synthesizing RTTI for the type of
`some_exception` in RTTI::getRTTI in
bridges/source/cpp_uno/gcc3_linux_powerpc64/except.cxx, which would need
definitions of __cxxabiv1::__class_type_info and
__cxxabiv1::__si_class_type_info.)  But hard to tell what exactly is
going wrong without actually debugging it.

> On 19-10-21 21:38:29, Piotr Kubaj wrote:
>> I'm trying to build LibreOffice 6.3.2 on FreeBSD/powerpc64 with LLVM 9.0.0 (elfv2 ABI).
>>
>> My problem is that I'm getting those errors https://pastebin.com/dKAY28ns
>>
>> I tried to patch them with https://pastebin.com/66Xhi1D1 using similar code to x86-64. But then I'm getting a segfault at postcmd stage at the end of compilation.

I would assume that something about the definitions of
__cxxabiv1::__class_type_info and __cxxabiv1::__si_class_type_info you
added to bridges/source/cpp_uno/gcc3_linux_powerpc64/share.hxx does not
match the definitions actually used by the system.

>> LibreOffice builds just fine with GCC 9.2, but this is still on elfv1. FreeBSD/powerpc* switches to LLVM for elfv2.

So where does such a GCC-based build find definitions of
__cxxabiv1::__class_type_info and __cxxabiv1::__si_class_type_info (in
some system header)?  How do those definitions differ from those you now
added to bridges/source/cpp_uno/gcc3_linux_powerpc64/share.hxx?


--
To unsubscribe e-mail to: [hidden email]
Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette
List archive: https://listarchives.libreoffice.org/global/users/
Privacy Policy: https://www.documentfoundation.org/privacy
Piotr Kubaj Piotr Kubaj
Reply | Threaded
Open this post in threaded view
|

Re: Building libreoffice with clang on ppc64

The definitions I put to LO's share.hxx are the same that were previously put to x86-64's share.hxx. Similar patches were also put in FreeBSD for i386 https://svnweb.freebsd.org/ports/head/editors/libreoffice/files/patch-bridges_source_cpp__uno_gcc3__linux__intel_share.hxx?view=markup&pathrev=496620

GCC9 has its definitions in its cxxabi.h and they are very different:
    402   class __class_type_info : public std::type_info
    403   {
    404   public:
    405     explicit
    406     __class_type_info (const char *__n) : type_info(__n) { }
    407
    408     virtual
    409     ~__class_type_info ();
    410
    411     // Implementation defined types.
    412     // The type sub_kind tells us about how a base object is contained
    413     // within a derived object. We often do this lazily, hence the
    414     // UNKNOWN value. At other times we may use NOT_CONTAINED to mean
    415     // not publicly contained.
    416     enum __sub_kind
    417       {
    418         // We have no idea.
    419         __unknown = 0,
    420
    421         // Not contained within us (in some circumstances this might
    422         // mean not contained publicly)
    423         __not_contained,
    424
    425         // Contained ambiguously.
    426         __contained_ambig,
    427
    428         // Via a virtual path.
    429         __contained_virtual_mask = __base_class_type_info::__virtual_mask,
    430
    431         // Via a public path.
    432         __contained_public_mask = __base_class_type_info::__public_mask,
    433
    434         // Contained within us.
    435         __contained_mask = 1 << __base_class_type_info::__hwm_bit,
    436
    437         __contained_private = __contained_mask,
    438         __contained_public = __contained_mask | __contained_public_mask
    439       };
    440
    441     struct __upcast_result;
    442     struct __dyncast_result;
    443
    444   protected:
    445     // Implementation defined member functions.
    446     virtual bool
    447     __do_upcast(const __class_type_info* __dst_type, void**__obj_ptr) const;
    448
    449     virtual bool
    450     __do_catch(const type_info* __thr_type, void** __thr_obj,
    451                unsigned __outer) const;
    452
    453   public:
    454     // Helper for upcast. See if DST is us, or one of our bases.
    455     // Return false if not found, true if found.
    456     virtual bool
    457     __do_upcast(const __class_type_info* __dst, const void* __obj,
    458                 __upcast_result& __restrict __result) const;
    459
    460     // Indicate whether SRC_PTR of type SRC_TYPE is contained publicly
    461     // within OBJ_PTR. OBJ_PTR points to a base object of our type,
    462     // which is the destination type. SRC2DST indicates how SRC
    463     // objects might be contained within this type.  If SRC_PTR is one
    464     // of our SRC_TYPE bases, indicate the virtuality. Returns
    465     // not_contained for non containment or private containment.
    466     inline __sub_kind
    467     __find_public_src(ptrdiff_t __src2dst, const void* __obj_ptr,
    468                       const __class_type_info* __src_type,
    469                       const void* __src_ptr) const;
    470
    471     // Helper for dynamic cast. ACCESS_PATH gives the access from the
    472     // most derived object to this base. DST_TYPE indicates the
    473     // desired type we want. OBJ_PTR points to a base of our type
    474     // within the complete object. SRC_TYPE indicates the static type
    475     // started from and SRC_PTR points to that base within the most
    476     // derived object. Fill in RESULT with what we find. Return true
    477     // if we have located an ambiguous match.
    478     virtual bool
    479     __do_dyncast(ptrdiff_t __src2dst, __sub_kind __access_path,
    480                  const __class_type_info* __dst_type, const void* __obj_ptr,
    481                  const __class_type_info* __src_type, const void* __src_ptr,
    482                  __dyncast_result& __result) const;
    483
    484     // Helper for find_public_subobj. SRC2DST indicates how SRC_TYPE
    485     // bases are inherited by the type started from -- which is not
    486     // necessarily the current type. The current type will be a base
    487     // of the destination type.  OBJ_PTR points to the current base.
    488     virtual __sub_kind
    489     __do_find_public_src(ptrdiff_t __src2dst, const void* __obj_ptr,
    490                          const __class_type_info* __src_type,
    491                          const void* __src_ptr) const;
    492   };
    493
    494   // Type information for a class with a single non-virtual base.
    495   class __si_class_type_info : public __class_type_info
    496   {
    497   public:
    498     const __class_type_info* __base_type;
    499
    500     explicit
    501     __si_class_type_info(const char *__n, const __class_type_info *__base)
    502     : __class_type_info(__n), __base_type(__base) { }
    503
    504     virtual
    505     ~__si_class_type_info();
    506
    507   protected:
    508     __si_class_type_info(const __si_class_type_info&);
    509
    510     __si_class_type_info&
    511     operator=(const __si_class_type_info&);
    512
    513     // Implementation defined member functions.
    514     virtual bool
    515     __do_dyncast(ptrdiff_t __src2dst, __sub_kind __access_path,
    516                  const __class_type_info* __dst_type, const void* __obj_ptr,
    517                  const __class_type_info* __src_type, const void* __src_ptr,
    518                  __dyncast_result& __result) const;
    519
    520     virtual __sub_kind
    521     __do_find_public_src(ptrdiff_t __src2dst, const void* __obj_ptr,
    522                          const __class_type_info* __src_type,
    523                          const void* __sub_ptr) const;
    524
    525     virtual bool
    526     __do_upcast(const __class_type_info*__dst, const void*__obj,
    527                 __upcast_result& __restrict __result) const;
    528   };

I guess I could put that to LO's powerpc64's share.hxx, but I doubt very much that it would build.

On-10-23 09:54:36, Stephan Bergmann wrote:

> On 22/10/2019 18:28, Piotr Kubaj wrote:
> > Here's the backtrace. The process that segfaults is gengan.bin:
> > #0  0x000000081baea134 in (anonymous namespace)::cpp_mediate(unsigned long, void**, void**, long, long*)
> >      (nOffsetAndIndex=60434681040, gpreg=0x3ffffffffffef830, fpreg=0x3ffffffffffef7c8, sp=4611686018427320272, pRegisterReturn=0x3ffffffffffef7b8)
> >      at bridges/source/cpp_uno/gcc3_linux_powerpc64/cpp2uno.cxx:396
> > #1  0x000000081bae9f50 in privateSnippetExecutor() () at bridges/source/cpp_uno/gcc3_linux_powerpc64/cpp2uno.cxx:563
> > #2  0x00000008121de234 in cppu::throwException(com::sun::star::uno::Any const&)Python Exception <class 'gdb.error'> No type named 挀漀洀⸀猀甀渀⸀猀琀愀爀⸀甀挀戀⸀䤀渀琀攀爀愀挀琀椀瘀攀
> > 䄀甀最洀攀渀琀攀搀䤀伀䔀砀挀攀瀀琀椀漀渀.:
> >   (exc=) at cppuhelper/source/exc_thrower.cxx:207
> > #3  0x000000081672ebd4 in ucbhelper::cancelCommandExecution(com::sun::star::ucb::IOErrorCode, com::sun::star::uno::Sequence<com::sun::star::uno::Any> const&, com::sun::star::uno::Reference<com::sun::star::ucb::XCommandEnvironment> const&, rtl::OUString const&, com::sun::star::uno::Reference<com::sun::star::ucb::XCommandProcessor> const&)
> >      (eError=com::sun::star::ucb::IOErrorCode::IOErrorCode_NOT_EXISTING, rArgs=
> >      uno::Sequence of length 2 = {...}, xEnv=empty uno::Reference, rMessage="an error occurred during file opening", xContext=uno::Reference to (fileaccess::BaseContent *) 0x81d0b5258) at ucbhelper/source/provider/cancelcommandexecution.cxx:109
>
> So this smells like it is indeed related to the changes in your below
> patch.  (The code is about synthesizing a C++ `throw some_exception`
> expression, which may require synthesizing RTTI for the type of
> `some_exception` in RTTI::getRTTI in
> bridges/source/cpp_uno/gcc3_linux_powerpc64/except.cxx, which would need
> definitions of __cxxabiv1::__class_type_info and
> __cxxabiv1::__si_class_type_info.)  But hard to tell what exactly is
> going wrong without actually debugging it.
>
> > On 19-10-21 21:38:29, Piotr Kubaj wrote:
> >> I'm trying to build LibreOffice 6.3.2 on FreeBSD/powerpc64 with LLVM 9.0.0 (elfv2 ABI).
> >>
> >> My problem is that I'm getting those errors https://pastebin.com/dKAY28ns
> >>
> >> I tried to patch them with https://pastebin.com/66Xhi1D1 using similar code to x86-64. But then I'm getting a segfault at postcmd stage at the end of compilation.
>
> I would assume that something about the definitions of
> __cxxabiv1::__class_type_info and __cxxabiv1::__si_class_type_info you
> added to bridges/source/cpp_uno/gcc3_linux_powerpc64/share.hxx does not
> match the definitions actually used by the system.
>
> >> LibreOffice builds just fine with GCC 9.2, but this is still on elfv1. FreeBSD/powerpc* switches to LLVM for elfv2.
>
> So where does such a GCC-based build find definitions of
> __cxxabiv1::__class_type_info and __cxxabiv1::__si_class_type_info (in
> some system header)?  How do those definitions differ from those you now
> added to bridges/source/cpp_uno/gcc3_linux_powerpc64/share.hxx?
>

--

--
To unsubscribe e-mail to: [hidden email]
Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette
List archive: https://listarchives.libreoffice.org/global/users/
Privacy Policy: https://www.documentfoundation.org/privacy
sberg sberg
Reply | Threaded
Open this post in threaded view
|

Re: Building libreoffice with clang on ppc64

On 23/10/2019 10:34, Piotr Kubaj wrote:
> The definitions I put to LO's share.hxx are the same that were previously put to x86-64's share.hxx. Similar patches were also put in FreeBSD for i386 https://svnweb.freebsd.org/ports/head/editors/libreoffice/files/patch-bridges_source_cpp__uno_gcc3__linux__intel_share.hxx?view=markup&pathrev=496620

The definitions used in other environments are not very relevant here.
The definitions used by RTTI::getRTTI must match those used by the
__cxa_throw et al functionality used at runtime (provided by libstdc++
or libc++abi or whatever your FreeBSD/powerpc64 environment uses.


--
To unsubscribe e-mail to: [hidden email]
Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette
List archive: https://listarchives.libreoffice.org/global/users/
Privacy Policy: https://www.documentfoundation.org/privacy