similar to: [lld] bug detecting undefined symbols in shared libraries

With shared libraries, it is always possible that you end up running with a different set of libraries than you actually linked with. However, how often is that actually the case? It seems at the very least there should be an option to tell the user that unless they switch libraries, their code won't be runnable. In most cases, everything is available to the linker to detect the situation

Hi all, sorry to post to both lists, but I'm running into an issue where clang-generated debug info is deemed to be invalid by LLVM tools (throws an assertion error in both llc and mcjit), and I'm not sure what the proper resolution is. Here's a test case; I last tested it on revision r210953: $ cat test1.cpp #include "test.h" test::Test<int> foo1() { return

Hi, here are a couple of strange things happening with R.2.2.0 compiled under Mandrake-10.1 At the begining of the story I have segmentation fault using package RandomFields in conjuction with some Fortran code of mine loaded with dyn.load. One of my fortran programs contains a subroutine named fstat Trying to trace , I simplified the sequence as much as possible and I end up with the the

+Adrian & Manman, Looks like this is a case of non-DIRef references ending up in the IR, and thus the references not being deduplicated. This could lead to some of the IR bloat that you guys implemented the DIRef stuff to reduce/avoid. The specific issue is that the type is slightly different in the two TUs (since the namespace scope it's contained within is different in the two TUs -

>> Without needing to change how namespaces are handled. >> >> Yes, using DIRefs for namespaces would cause the actual type nodes to >> be deduplicated when they aren't even with the patch above, and that >> would help reduce debug info metadata further if that's >> useful/necessary. > > Exactly. While the above patch will cover up the problem, we

On Tue, Jun 24, 2014 at 2:38 PM, Adrian Prantl <aprantl at apple.com> wrote: > I will take this. > > !5 = metadata !{metadata !"./test.h", metadata !"/Volumes/Data/radar/17052973"} > !6 = metadata !{i32 786489, metadata !5, null, metadata !"test", i32 1} ; [ DW_TAG_namespace ] [test] [line 1] > !4 = metadata !{i32 786434, metadata !5, metadata !6,

Most ELF shared libraries can be sliced in two ways. One is following the information in the program headers (e_phoff). The other is following the information in the section headers (e_shoff). Regular relocatable objects only have the section header. At runtime, the dynamic linker only uses the program headers. In fact, the section headers is optional. When given a shared library, how should

I looked into this a little. My proposal is this: - extend DINamespace with an extra UniqueID filed (analogous to DICompositeType) - add an extra case to DIScope::getRef() - Let CGDebugInfo create a mangled name for each namespace to use as UID -> the UID of the anonymous namespace is null. For example: namespace a { namespace b {} } -> “_ZN1a", “_ZN1a1b" !0 = [compile unit]

> On Jun 27, 2014, at 1:58 PM, David Blaikie <dblaikie at gmail.com> wrote: > > On Fri, Jun 27, 2014 at 1:49 PM, Adrian Prantl <aprantl at apple.com> wrote: >> I looked into this a little. > > Thanks for taking a look! > >> My proposal is this: >> >> - extend DINamespace with an extra UniqueID filed (analogous to DICompositeType) >> -

On Fri, Jun 27, 2014 at 2:19 PM, David Blaikie <dblaikie at gmail.com> wrote: > On Fri, Jun 27, 2014 at 2:15 PM, Adrian Prantl <aprantl at apple.com> wrote: >> >>> On Jun 27, 2014, at 1:58 PM, David Blaikie <dblaikie at gmail.com> wrote: >>> >>> On Fri, Jun 27, 2014 at 1:49 PM, Adrian Prantl <aprantl at apple.com> wrote: >>>>

ninja all check-xray [0/981] Building libLLVMTableGen for native TableGen... ninja: no work to do. [673/979] Linking CXX shared library lib/liblldCommon.so.6.0.0svn FAILED: lib/liblldCommon.so.6.0.0svn : && /usr/bin/clang++-3.9 -fPIC -Wpedantic -fPIC -fvisibility-inlines-hidden -Werror=date-time -std=c++11 -Wall -W -Wno-unused-parameter -Wwrite-strings -Wcast-qual

I am nuilding that now. CC=clang CXX=clang++ cmake -DCMAKE_INSTALL_PREFIX=$HOME/opt/llvm11-git \ -DCMAKE_BUILD_TYPE=Release \ -DBUILD_SHARED_LIBS=ON \ -DLLVM_ENABLE_EH=ON \ -DLLVM_ENABLE_RTTI=ON \ -DLLVM_HOST_TRIPLE=x86_64-pc-linux-gnu \ -DLLVM_TARGETS_TO_BUILD="AMDGPU;MSP430;WebAssembly;X86" \

On 2020-03-29, Nemanja Ivanovic via llvm-dev wrote: >Glad you got it working. >My suggestion about LLVM_ENABLE_THREADS didn't work because you didn't >apply it when building the build linker. > >When you don't have the ability to rebuild the build compiler, this doesn't >apply. In those cases, I end up doing a dirty hack where I use a wrapper >script with

Hi, Using master at b0a1c0b72c9c61f8b0a223e08f43498abb64f5e8, I cannot build LLVM. I configured with: CC=clang CXX=clang++ cmake -DCMAKE_INSTALL_PREFIX=$HOME/opt/llvm11-git \ -DCMAKE_BUILD_TYPE=Release \ -DLLVM_BUILD_LLVM_DYLIB=ON \ -DLLVM_LINK_LLVM_DYLIB=ON \ -DBUILD_SHARED_LIBS=OFF \ -DLLVM_ENABLE_EH=ON \ -DLLVM_ENABLE_RTTI=ON \

$ free -g total used free shared buff/cache available Mem: 376 149 20 1 207 225 Swap: 3 0 3 Too small swap size for a 72-core login machine? On Sun, Mar 29, 2020 at 4:28 AM Alex Brachet-Mialot < alexbrachetmialot at gmail.com> wrote: > Enable threads is for building llvm with

Alex : Can you please try `numactl` or `taskset` after https://github.com/llvm/llvm-project/commit/09158252f777c2e2f06a86b154c44abcbcf9bb74 ? There was a tiny bug in how sched_getaffinity() was used, see: https://reviews.llvm.org/D75153#1942336 De : Alex Brachet-Mialot <alexbrachetmialot at gmail.com> Envoyé : March 28, 2020 12:11 PM À : Itaru Kitayama <itaru.kitayama at gmail.com>

Hi, My configuration is below: cmake -GNinja -DLLVM_ENABLE_LLD=ON -DLLVM_ENABLE_THREADS=OFF -DLLVM_ENABLE_LIBCXX=ON -DCMAKE_BUILD_TYPE=Release -DGCC_INSTALL_PREFIX=/home/usr4/c74014i/opt/gcc-7.5.0/ -DLIBOMPTARGET_ENABLE_DEBUG=ON -DCMAKE_INSTALL_PREFIX=$HOME/opt/clang/${today} -DCMAKE_C_COMPILER=clang -DCMAKE_C_FLAGS="" -DCMAKE_CXX_COMPILER=clang++ -DCMAKE_CXX_FLAGS=""

Here is the structure of my servers : Source : /home/test1/link_dir sub_dir1 file1 file2 ... sub_dir2 ... Destination: /home/test2/real_dir sub_dir1 file1 file2 ... subdir2

Hi All, This test is on a ubuntu 12 box. Can anyone please point me what revision/commit-id of lld fixed this issue which was atleast in llvm 5.0. . ├── build.sh ├── main.c ├── shared │ └── sh.c └── static └── st.c [[ build.sh ]] #!/bin/sh CC="${TOOLCHAIN}/bin/clang" AR="${TOOLCHAIN}/bin/llvm-ar" CFLAGS="-g -O" LDFLAGS="-fuse-ld=lld" rm

Hello, I am trying to compile some F77 subroutines as shared objects for R on my Mac. --> Mac OS-X Version 10.4.11 (Tiger Intel Mac) I have done this (successfully) before on Sun Solaris and Linux Fedora systems using the following command. > R CMD SHLIB myfile.f I have g77 installed from this page. http://hpc.sourceforge.net/ I am using R 2.8.1, and I have installed all 4 additional