search for: __dso_handle

This is a followup to the discussion that started in D28791. To provide the context, we need a way to provide __dso_handle in Fuchsia. __dso_handle symbol is mandated by C++ ABI with a value which is an address in one of the object's segments, and as such this symbol has to be included statically and cannot be a part of a shared library. Different systems provide it differently: 1. On GNU/Linux systems, it's d...

...01 PM Sean Silva <chisophugis at gmail.com> wrote: > On Thu, Jun 1, 2017 at 8:47 PM, Petr Hosek via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> This is a followup to the discussion that started in D28791. To provide >> the context, we need a way to provide __dso_handle in Fuchsia. __dso_handle >> symbol is mandated by C++ ABI with a value which is an address in one of >> the object's segments, and as such this symbol has to be included >> statically and cannot be a part of a shared library. Different systems >> provide it differently:...

Ashok Nalkund wrote: > > Resending :(. Any pointers? Fundamentally the issue is that the system linker is supposed to define __dso_handle when linking, but since there is no system linker between your build of the .bc files and running lli, nobody has defined it. It seems reasonable to me that lli should define __dso_handle if it's declared in the module. You could module tools/lli/lli.cpp to add a global: char *dummy_dso...

...e '::_1::' part). That >> won't work. >> >> Nick > > Thanks for the clue. I had earlier tried to use libc++ and there were > some remnants of that try. I've now cleaned up and now it gets past the > use_facet error. > > It now complains about '__dso_handle'. I saw a bug already reported but > its status is still NEW: > http://llvm.org/bugs/show_bug.cgi?id=7847 > > As mentioned in the bug, the problem seems to be when the interpreter is > used. > > There is another post on cfe-dev list: > http://clang-developers.42468.n3.na...

...ve -mtune=native -DSPILLING_ENSUES=0 /* no spilling */ $ objdump -dC --no-show-raw-insn ./a.out ... 00000000004004f0 <main>: 4004f0: vmovdqa 0x2004c8(%rip),%xmm0 # 6009c0 <x> 4004f8: vpsrld $0x17,%xmm0,%xmm0 4004fd: vpaddd 0x17b(%rip),%xmm0,%xmm0 # 400680 <__dso_handle+0x8> 400505: vcvtdq2ps %xmm0,%xmm1 400509: vdivps 0x17f(%rip),%xmm1,%xmm1 # 400690 <__dso_handle+0x18> 400511: vcvttps2dq %xmm1,%xmm1 400515: vpmullw 0x183(%rip),%xmm1,%xmm1 # 4006a0 <__dso_handle+0x28> 40051d: vpsubd %xmm1,%xmm0,%xmm0 400521: vm...

Hi Nick, > Fundamentally the issue is that the system linker is supposed to define > __dso_handle when linking, but since there is no system linker between > your build of the .bc files and running lli, nobody has defined it. > > It seems reasonable to me that lli should define __dso_handle if it's > declared in the module. > > You could module tools/lli/lli.cpp to add a g...

...g -cc1 -emit-llvm-bc -x c++ | lli -use-mcjit echo -e '#include <iostream>\nint main(){ std::cout << "hello" << std::endl; }' | clang -cc1 -emit-llvm-bc -x c++ | lli Each of these commands results in "LLVM ERROR: Could not resolve external global address: __dso_handle": echo -e '#include <iostream>\nint main(){ std::cout << "hello" << std::endl; }' | clang -cc1 -emit-llvm-bc -x c++ | lli -force-interpreter=true echo -e '#include <iostream>\nint main(){ std::cout << "hello" << std::endl...

...dtors,"aw", at progbits > .align 8 > __DTOR_LIST__: # __DTOR_LIST__ > .size __DTOR_LIST__, 8 > .quad 4294967295 > > .type __JCR_LIST__, at object > .section .jcr > .align 8 > __JCR_LIST__: # __JCR_LIST__ > .size __JCR_LIST__, 0 > > .hidden __dso_handle > .type __dso_handle, at object > .globl __dso_handle > .data > .align 8 > __dso_handle: # __dso_handle > .size __dso_handle, 8 > .zero 8 > > .type p.4704, at object > .align 8 > p.4704: # p.4704 > .size p.4704, 8 > .quad (__DTOR_LIST__) + 8 &g...

> Resending :(. Any pointers? Are you seeing missing __dso_handle with the interpreter or with the JIT? Ciao, Duncan. > > tia > > On 5/21/2012 2:46 PM, Ashok Nalkund wrote: >> On 5/21/2012 11:15 AM, Nick Lewycky wrote: >>> Ashok Nalkund wrote: >>>> Resending, any pointers? I demangled the symbol and it turns out to be: &gt...

Does anyone have any ideas why my recently updated * 1.2.5 system should spawn multiple * process at seemingly random intervals? Regards L:ee ########################################### This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange. For more information, connect to http://www.f-secure.com/ -------------- next part -------------- An HTML attachment was scrubbed...

..._LIST__, 8 > > .quad 4294967295 > > > > .type __JCR_LIST__, at object > > .section .jcr > > .align 8 > > __JCR_LIST__: # __JCR_LIST__ > > .size __JCR_LIST__, 0 > > > > .hidden __dso_handle > > .type __dso_handle, at object > > .globl __dso_handle > > .data > > .align 8 > > __dso_handle: # __dso_handle > > .size __dso_handle, 8 > > .zero 8 > > > > .type p.4704, at...

Hi all, I've run into problems compiling the llvm-gcc frontend on x86_64. Is this not supported, or am I making an error somewhere? The procedure I followed was: 1. Download LLVM 2.0 source as a tarball (from a few days ago, during the testing phase). 2. Download the llvm-gcc4 source today, as a tarball. 3. Extract both. 4. Configure LLVM as: ../src/configure --prefix=`pwd`../install

...t = "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:64-f32:32:32-f64:32:64-v64:64:64-v128:128:128-a0:0:64-f80:128:128-n8:16:32" target triple = "i386-apple-darwin10" %0 = type { i32, void ()* } %class.Foo = type { i32 } @foo = global %class.Foo zeroinitializer, align 4 @__dso_handle = external global i8* @.str = private unnamed_addr constant [6 x i8] c"~Foo\0A\00" @.str1 = private unnamed_addr constant [5 x i8] c"Foo\0A\00" @llvm.global_ctors = appending global [1 x %0] [%0 { i32 65535, void ()* @_GLOBAL__I_a }] define internal void @__cxx_global_var_init(...

...cts/VMP_SDK_llvm1.8_gil/generated-llvm/obj/utils/TableGen/Debug/AsmWriterEmitter.o: In function `_Z41__static_initialization_and_destruction_0ii': AsmWriterEmitter.cpp:(.text+0x70): undefined reference to `_ZNSt8ios_base4InitC1Ev' AsmWriterEmitter.cpp:(.text+0x78): undefined reference to `__dso_handle' AsmWriterEmitter.cpp:(.text+0x8c): undefined reference to `__cxa_atexit' AsmWriterEmitter.cpp:(.text+0x94): undefined reference to `_ZN4llvm19SupportIsInfLinkVarE' AsmWriterEmitter.cpp:(.text+0xa0): undefined reference to `_ZN4llvm11IncludeFileC1EPv' AsmWriterEmitter.cpp:(.text+0...

...__run_exit_handlers(). I can't tell from gdb what exit handler is crashing, but no calls are made to atexit() or on_exit(); all exit handlers are installed via __cxa_atexit(). This may or may not be meaningful, but I am forced to compile with -fno-use-cxa-atexit, otherwise clang complains that __dso_handle could not be resolved. Any guidance would be MUCH appreciated. I am at a loss... Also, if you know of a better place to look for help than this mailing list, that would be appreciated, too. Thanks, Geoff -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://li...

...e to help. Type "q()" to quit R. > dyn.load(paste("nc2r", .Platform$dynlib.ext, sep="")) Error in dyn.load(x, as.logical(local), as.logical(now)) : unable to load shared library "/home/kareb/netcdf/nc2r.so": /home/kareb/netcdf/nc2r.so: undefined symbol: __dso_handle The symbol "__dso_handle" I presume is defined in Rinternals.h or some R-routines, or am I wrong? Are my R-path set incorrectly? Why does R say that it cannot load nc2r.so, when this file is in the local directory? There were some clashes between definitions in R.h and Rinternals.h, so I...

...8:8-i16:16:16-i32:32:32-i64:32:64-f32:32:32-f64:32:64-v64:64:64-v128:128:128-a0:0:64-f80:128:128-n8:16:32" > target triple = "i386-apple-darwin10" > > %0 = type { i32, void ()* } > %class.Foo = type { i32 } > > @foo = global %class.Foo zeroinitializer, align 4 > @__dso_handle = external global i8* > @.str = private unnamed_addr constant [6 x i8] c"~Foo\0A\00" > @.str1 = private unnamed_addr constant [5 x i8] c"Foo\0A\00" > @llvm.global_ctors = appending global [1 x %0] [%0 { i32 65535, void ()* @_GLOBAL__I_a }] > > define internal void...

Hello Pushkar, >I get the error Could not resolve external global address: __dso_handle Based on what I've read on the mailing list in the past, that's because the interpreter doesn't support non-bitcode external addresses such as the function calls used to do input and output of data. As such the interpreter is quite useless in its current state. If you use JIT compila...

...doesn't use inline namespaces, the '::_1::' part). That > won't work. > > Nick Thanks for the clue. I had earlier tried to use libc++ and there were some remnants of that try. I've now cleaned up and now it gets past the use_facet error. It now complains about '__dso_handle'. I saw a bug already reported but its status is still NEW: http://llvm.org/bugs/show_bug.cgi?id=7847 As mentioned in the bug, the problem seems to be when the interpreter is used. There is another post on cfe-dev list: http://clang-developers.42468.n3.nabble.com/Configuring-HAVE-DSO-HANDLE...

Hello, Can LLVM execute OpenGL ES 2.0 programs safely? As I tried a simple code, and I get some crashes while using lli example LLVM ERROR: Program used external function '__dso_handle' which could not be resolved! Thanks in advance Sara Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ? Je crée ma boîte mail www.laposte.net -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-...