search for: __cxa_guard_acquire

...unter15registerCounterENS_9StringRefES1_ _ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE9_M_createERmm 4 _ZN4llvm16FileOutputBuffer6createENS_9StringRefEmj _Znwm 4 LLVMInitializeMipsTargetInfo __cxa_guard_release 4 LLVMInitializeARMTargetInfo __cxa_guard_release 4 LLVMInitializeMipsTargetInfo __cxa_guard_acquire 4 LLVMInitializeARMTargetInfo __cxa_guard_acquire 4 _ZN4llvm12DebugCounter15registerCounterENS_9StringRefES1_ _ZdlPv 4 _ZNSt8_Rb_treeINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESt4pairIKS5_jESt10_Select1stIS8_ESt4lessIS5_ESaIS8_EE8_M_eraseEPSt13_Rb_tree_nodeIS8_E _ZdlPv 4 _ZN4llvm3opt12Inp...

A rebased version of the lld patch is attached. Cheers, Rafael On 31 July 2017 at 15:11, Rafael Avila de Espindola <rafael.espindola at gmail.com> wrote: > Tobias Edler von Koch <tobias at codeaurora.org> writes: > >> Hi Rafael, >> >> On 07/31/2017 04:20 PM, Rafael Avila de Espindola via llvm-dev wrote: >>> However, do we need to start with

I'm working with an experimental backend for an MCU with heavy multithreading capabilities but lacks proper acquire/release semantics. This is okay, as the programmer can customize __cxa_guard_acquire and __cxa_guard_release to lower/raise appropriate semaphores. The issue I'm having is that I can't seem to figure out when to lower atomic load into an acquire/load pair early enough that the __cxa_guard_acquire is evaluated for optimization (most importantly inlining.) First, is thi...

...home/jonasbu/local/bin $ clang -fxray-instrument minimal.c /home/jonasbu/local/lib/clang/6.0.0/lib/linux/libclang_rt.xray-x86_64.a(xray_inmemory_log.cc.o): In function `getGlobalFd()': /home/jonasbu/llvm-clang/llvm/projects/compiler-rt/lib/xray/xray_inmemory_log.cc:123: undefined reference to `__cxa_guard_acquire' /home/jonasbu/llvm-clang/llvm/projects/compiler-rt/lib/xray/xray_inmemory_log.cc:123: undefined reference to `__cxa_guard_release' /home/jonasbu/local/lib/clang/6.0.0/lib/linux/libclang_rt.xray-x86_64.a(xray_inmemory_log.cc.o): In function `__xray_InMemoryRawLog<__xray_InMemoryEmulateTS...

..._TARGET_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...

...TLIB=compiler-rt LLVM_DEFAULT_TARGET_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...

...with a particular parameter? . . [ 52%] Built target gtest [ 52%] Built target gtest_main Linking CXX shared library ../../../lib/libc++.so CMakeFiles/cxx.dir/__/src/ios.cpp.o: In function `std::__1::iostream_category()': /opt/llvm/llvm/projects/libcxx/src/ios.cpp:71: undefined reference to `__cxa_guard_acquire' /opt/llvm/llvm/projects/libcxx/src/ios.cpp:71: undefined reference to `__cxa_guard_release' CMakeFiles/cxx.dir/__/src/ios.cpp.o: In function `std::__1::ios_base::clear(unsigned int)': CMakeFiles/cxx.dir/__/src/ios.cpp.o: In function `std::__1::basic_istream<char, std::__1::char_trai...

...; . > . > [ 52%] Built target gtest > [ 52%] Built target gtest_main > Linking CXX shared library ../../../lib/libc++.so > CMakeFiles/cxx.dir/__/src/ios.cpp.o: In function `std::__1::iostream_category()': > /opt/llvm/llvm/projects/libcxx/src/ios.cpp:71: undefined reference to `__cxa_guard_acquire' > /opt/llvm/llvm/projects/libcxx/src/ios.cpp:71: undefined reference to `__cxa_guard_release' > CMakeFiles/cxx.dir/__/src/ios.cpp.o: In function `std::__1::ios_base::clear(unsigned int)': > CMakeFiles/cxx.dir/__/src/ios.cpp.o: In function `std::__1::basic_istream<char, std:...

...> [ 52%] Built target gtest > [ 52%] Built target gtest_main > Linking CXX shared library ../../../lib/libc++.so > CMakeFiles/cxx.dir/__/src/ios.cpp.o: In function > `std::__1::iostream_category()': > /opt/llvm/llvm/projects/libcxx/src/ios.cpp:71: undefined reference to > `__cxa_guard_acquire' > /opt/llvm/llvm/projects/libcxx/src/ios.cpp:71: undefined reference to > `__cxa_guard_release' > CMakeFiles/cxx.dir/__/src/ios.cpp.o: In function > `std::__1::ios_base::clear(unsigned int)': > CMakeFiles/cxx.dir/__/src/ios.cpp.o: In function > `std::__1::basic_istrea...

[Sorry about the crosspost. Since this is a clang build question but the build is invoked from the top-level LLVM directory I'm not sure where the question should go.] I've got a clang build against libstdc++ on Linux but I would really like one built against libc++/libc++abi. In other words I'd like to rebuild clang/llvm with clang using libc++ and libc++abi on Linux. I looked at

Hi Ioannis, If you only want the clang static analyzer, there is no need to check out and build libc++ as part of the process. The rest of the build can just use the system C++ library, which will be libstdc++ on Xubuntu. That said, without the full build log, it is hard to say what went wrong. Specifically, which references were undefined? -Dimitry > On 26 Mar 2016, at 16:04, Ioannis

...it dynamic initialization code for weak globals, unless we can prove that every translation unit will use static initialization. In TUs where the value can be folded, we emit that value as a weak_odr constant. The dynamic initialization code works like this: if (((char*)guard)[0] == 0) { if (__cxa_guard_acquire(guard)) { if (object is zero-initialized) { try { ... initialize object ... } catch (...) { __cxa_guard_abort(guard); throw; } ... enqueue dtor with __cxa_atexit ... } __cxa_guard_release(guard); } } The zero-ini...

...ad parameter at this point. To double check what image is 0x0000000100ebb499 and 0x0000000100f5f96e in ? LLVMPolly.so? It looks like it is trying to call __cxa_guard_release (at least gdb thinks that). That is odd for the start of an initializer. There should have been a previous call to __cxa_guard_acquire. For reference, here is stepping through hello-world: (gdb) disassemble main Dump of assembler code for function main: 0x0000000100000f00 <main+0>: push %rbp 0x0000000100000f01 <main+1>: mov %rsp,%rbp 0x0000000100000f04 <main+4>: sub $0x10,%rsp 0x0000000100000f08 <m...

...LVMSupport.a -lrt -ldl > -lncurses -lpthread -lz -lm -Wl,-rpath,"\$ORIGIN/../lib" > ../../../../lib/libLLVMSupport.a(Debug.cpp.o): In function `llvm::dbgs()': > /ptmp/dag/llvm/llvm-ecosystem/llvm/lib/Support/Debug.cpp:(.text._ZN4llvm4dbgsEv+0x1b): > undefined reference to `__cxa_guard_acquire' > /ptmp/dag/llvm/llvm-ecosystem/llvm/lib/Support/Debug.cpp:(.text._ZN4llvm4dbgsEv+0x11a): > undefined reference to `__cxa_guard_release' > > And a bazillion other undefined references. > > Is the problem the lack of -lc++abi on the link line? That command > comes from...

Hello everybody, I am very new to llvm and I am struggling to install it on my 15.10 Xubuntu with kernel 4.2.0-34-generic #39-Ubuntu SMP x86_64 GNU/Linux. I essentially intend to use the clang static analyzer, but it seems that I have to build it on top of llvm and clang. Unfortunately I run into the following problem. CXX shared library ../../../lib/libc++.so at around 52% of the procedure

2011/11/7 Rafael Espíndola <rafael.espindola at gmail.com>: > I tried a small variation: > > struct S { >  static const int x; > }; > template<typename T> struct U { >  static const int k; > }; > template<typename T> const int U<T>::k = T::x; > > #ifdef TU1 > extern int f(); > const int S::x = 42; > int main() { >  return f() +

On Tue, Oct 23, 2012 at 02:03:15PM -0700, Nick Kledzik wrote: > > On Oct 23, 2012, at 1:57 PM, Jack Howarth wrote: > > Nick, > > Can I do this without access to a debug version of dyld? Using the copy of LLVMPolly.so with isl/cloog-isl/gmp statically linked, > > I find that if I set the breakpoint to the address of the initializer... > > > > dyld: calling

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

Hello, I recognized that compiler-rt's the implementation of __aeabi_memcpy simply branches to memcpy. The implementation of memcpy is not provided. So an externally provided memcpy () has to be used. (also applies to memmove, memset, memclr) On ARM I have seen implementations of memcpy () using floating-point registers (if compiled with NEON support). The is perfectly legal, as memcpy ()