[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [libreoffice-users] 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: users+unsubscribe@global.libreoffice.org
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

Follow-Ups:
Re: [libreoffice-users] Re: Building libreoffice with clang on ppc64Stephan Bergmann <sbergman@redhat.com>
Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.