search for: __cxa_pure_virtual

I recently updated my version of LLVM from revision 140108 to 142082, and several things broke, most of which were easily fixed. However, I'm now getting a "pure virtual method called" exception (__cxa_pure_virtual) which I wasn't getting before. This is happening in the destructor of a statically-initialized object. (More precisely, it's blowing up in a BumpPtrAllocator, which is used by a StringMap, which is in turn a member of a statically initialized object.) Anyone know what might have changed r...

...011 at 9:20 PM, Talin <viridia at gmail.com> wrote: > >> I recently updated my version of LLVM from revision 140108 to 142082, and >> several things broke, most of which were easily fixed. However, I'm now >> getting a "pure virtual method called" exception (__cxa_pure_virtual) which >> I wasn't getting before. This is happening in the destructor of a >> statically-initialized object. (More precisely, it's blowing up in a >> BumpPtrAllocator, which is used by a StringMap, which is in turn a member of >> a statically initialized object.) &g...

...ot;a->test(1);". CS.getCalledFunction() - return NULL, so we can say that this call site is virtual. My optimization determines, that in this call site B::test() should be called. I've tried to use CSn.setCalledFunction(F) (where F is B::test()), but I've got this: Check function __cxa_pure_virtual Call parameter type does not match function signature! %6 = load %class.A** %a, align 4 %class.B* call void @_ZN1B4testEi(%class.A* %6, i32 1) Ok! I've tried to change the first %class.A %6 to %class.B %6 by "FirstArgumentOfCS->get()->mutateType(FunctionFirstArgement->getType...

...n Sat, Oct 15, 2011 at 9:20 PM, Talin <viridia at gmail.com> wrote: > I recently updated my version of LLVM from revision 140108 to 142082, and > several things broke, most of which were easily fixed. However, I'm now > getting a "pure virtual method called" exception (__cxa_pure_virtual) which > I wasn't getting before. This is happening in the destructor of a > statically-initialized object. (More precisely, it's blowing up in a > BumpPtrAllocator, which is used by a StringMap, which is in turn a member of > a statically initialized object.) > > Anyone k...

...Talin <viridia at gmail.com> wrote: >> >>> I recently updated my version of LLVM from revision 140108 to 142082, and >>> several things broke, most of which were easily fixed. However, I'm now >>> getting a "pure virtual method called" exception (__cxa_pure_virtual) which >>> I wasn't getting before. This is happening in the destructor of a >>> statically-initialized object. (More precisely, it's blowing up in a >>> BumpPtrAllocator, which is used by a StringMap, which is in turn a member of >>> a statically initial...

...t; LLVM_TARGET_ARCH=x86_64 >> LLVM_TARGETS_TO_BUILD=X86 >> >> When linking libc++.so there are a lot of undefined references to __cxa_allocate_exception, __cxa_begin_catch, __cxa_end_catch, __cxa_free_exception, __cxa_guard_abort, __cxa_guard_acquire, __cxa_guard_release, __cxa_pure_virtual, __cxa_rethrow, __cxa_throw, __gxx_personality_v0, _Unwind_Resume, vtable for __cxxabiv1::__class_type_info, vtable for __cxxabiv1::__si_class_type_info, vtable for __cxxabiv1::__vmi_class_type_info. The full output of the linking command is too long and is attached gzipped. The linking command is...

...TRIPLE=x86_64-pc-linux-musl LLVM_TARGET_ARCH=x86_64 LLVM_TARGETS_TO_BUILD=X86 When linking libc++.so there are a lot of undefined references to __cxa_allocate_exception, __cxa_begin_catch, __cxa_end_catch, __cxa_free_exception, __cxa_guard_abort, __cxa_guard_acquire, __cxa_guard_release, __cxa_pure_virtual, __cxa_rethrow, __cxa_throw, __gxx_personality_v0, _Unwind_Resume, vtable for __cxxabiv1::__class_type_info, vtable for __cxxabiv1::__si_class_type_info, vtable for __cxxabiv1::__vmi_class_type_info. The full output of the linking command is too long and is attached gzipped. The linking command is...

...f a class's virtual functions between DSOs, and there are more practical cases where we might expect to see cross-DSO references: > > - one DSO could derive from a class defined in another DSO, and only override some of its virtual functions > - the vtable could contain a reference to __cxa_pure_virtual which would be defined by the standard library > > We can handle these cases by having the vtable refer to a PLT entry for each function that is not defined within the module. This can be done by using a specific type of relative relocation that refers directly to the symbol if defined withi...

...'s virtual functions between DSOs, and there are more practical cases > where we might expect to see cross-DSO references: > > - one DSO could derive from a class defined in another DSO, and only > override some of its virtual functions > - the vtable could contain a reference to __cxa_pure_virtual which would > be defined by the standard library > > We can handle these cases by having the vtable refer to a PLT entry for > each function that is not defined within the module. This can be done by > using a specific type of relative relocation that refers directly to the > symb...

...d.so.1 #2 0x287a0c1b in abort () from /lib/libc.so.5 #3 0x28864b69 in __gnu_cxx::__verbose_terminate_handler () from /usr/lib/libstdc++.so.4 #4 0x288692ba in __cxxabiv1::__terminate () from /usr/lib/libstdc++.so.4 #5 0x288692f0 in std::terminate () from /usr/lib/libstdc++.so.4 #6 0x288607a8 in __cxa_pure_virtual () from /usr/lib/libstdc++.so.4 #7 0x285e8a99 in MP4IntegerProperty::GetValue () from /usr/local/lib/libmp4v2.so.0 #8 0x285f4b5e in MP4Track::GetSampleFileOffset () from /usr/local/lib/libmp4v2.so.0 #9 0x285f28e4 in MP4Track::ReadSample () from /usr/local/lib/libmp4v2.so.0 #10 0x285df24b in MP4F...

...th a non-pure virtual function definition) and single-implementation (i.e. multiple derived classes all sharing a virtual function definition from a base class) devirtualization by checking that each of the possible values loaded from the vtables in the bitset are either identical or __cxa_pure_virtual (calls to pure virtuals are UB, so we’d be fine disregarding them), and propagating the identical address into the function callee. - The pass could also potentially implement speculative devirtualization (i.e. testing the vtable entry and guarding direct calls on it) by generating a c...

...d)...done. Loaded symbols for /libexec/ld-elf.so.1 #0 0x00000008013cc0da in kill () from /lib/libc.so.7 [New Thread 801c2b800 (LWP 101632/doveadm)] (gdb) bt #0 0x00000008013cc0da in kill () from /lib/libc.so.7 #1 0x00000008013ca809 in abort () from /lib/libc.so.7 #2 0x0000000802cf7b39 in __cxa_pure_virtual () from /lib/libcxxrt.so.1 #3 0x00000008025159dc in lucene::store::BufferedIndexOutput::~BufferedIndexOutput () from /usr/local/lib/libclucene-core.so.1 #4 0x000000080251717a in lucene::store::FSDirectory::FSIndexOutput::FSIndexOutput () from /usr/local/lib/libclucene-core.so.1 #5 0x000000080...

...9;s virtual functions between DSOs, and there are more practical cases where we might expect to see cross-DSO references: >> >> - one DSO could derive from a class defined in another DSO, and only override some of its virtual functions >> - the vtable could contain a reference to __cxa_pure_virtual which would be defined by the standard library >> >> We can handle these cases by having the vtable refer to a PLT entry for each function that is not defined within the module. This can be done by using a specific type of relative relocation that refers directly to the symbol if defin...

Hello all, Pardon me if this has already been covered elsewhere, however I have not been able to find such documentation. Is there a consolidated set of documentation that clearly explains what's necessary to port LLVM to other OSes & how to add support for building executables (& libraries) for those OSes? I'm searching through the source in an attempt to understand what needs to

Thank you for both of your input. Yes, I try to cross-compile for AVR, the simple ATMEGA328P used in every Arduino Uno. My main motivation being that I hope to be able to use a couple of STL containers, <functional> and <type_traits> on the MCU. Not sure though if this can be reached by going via the clang route. Getting back to the compilation: when I run clang with both both

Hi all, I'd like to make a proposal to implement the new vtable ABI described in PR26723, which I'll call the relative ABI. That bug gives more details and justification for that ABI. The user interface for the new ABI would be that -fwhole-program-vtables would take an optional value indicating which aspects of the program have whole-program scope. For example, the existing

...ction definition) and single-implementation >> (i.e. multiple derived classes all sharing a virtual function definition >> from a base class) devirtualization by checking that each of the possible >> values loaded from the vtables in the bitset are either identical or >> __cxa_pure_virtual (calls to pure virtuals are UB, so we’d be fine >> disregarding them), and propagating the identical address into the >> function callee. >> - The pass could also potentially implement speculative devirtualization >> (i.e. testing the vtable entry and guarding direct call...

...5 GLIBC_2.2.5 getpgid 0000000000000000 DF *UND* 00000000000000fc GLIBC_2.2.5 pthread_setspecific 0000000000000000 DF *UND* 0000000000000098 GLIBC_2.2.5 popen 0000000000000000 DF *UND* 0000000000000086 GLIBC_2.2.5 strsep 0000000000000000 DF *UND* 000000000000000f Base __cxa_pure_virtual 0000000000000000 DF *UND* 000000000000005e GLIBC_2.2.5 connect 0000000000000000 DF *UND* 0000000000000003 Base _ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE4syncEv 0000000000000000 DF *UND* 000000000000000b GLIBC_2.2.5 posix_spawn_file_actions_init 0000000000000000...

Hello, I update my building scripts to build LLVM 4.0 RC1 (with clang, lldb, libc++, libc++abi, lld) on CentOS 6 and I got a lot of undefined symbols during linking LLDB. I'm using clang-3.9 and this configuration: -DLLVM_TARGETS_TO_BUILD="X86" -DCMAKE_BUILD_TYPE=Release -DCMAKE_C_COMPILER=/usr/bin/clang -DCMAKE_CXX_COMPILER=/usr/bin/clang++