search for: phosek

...ied it and I get this: CMake Error at projects/libcxx/CMakeLists.txt:361 (message): LIBCXX_ENABLE_STATIC_ABI_LIBRARY is not supported on OS X Why is it not supported? If I manually embed libc++abi.a inside libc++.a it seems to work. Thanks! ardi On Mon, Oct 1, 2018 at 4:20 AM Petr Hosek <phosek at chromium.org> wrote: > > You can use LIBCXX_ENABLE_STATIC_ABI_LIBRARY=ON CMake option to statically link libc++abi into libc++.a. You can also use LIBCXX_STATICALLY_LINK_ABI_IN_SHARED_LIBRARY=OFF to disable statically linking libc++abi into libc++.so (i.e. libc++abi will only be merged...

> On Aug 8, 2020, at 3:32 PM, Dmitry Mikushin via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Cool, thanks! > > вс, 9 авг. 2020 г. в 00:27, Petr Hosek <phosek at chromium.org <mailto:phosek at chromium.org>>: > You can set the LLVM_PARALLEL_LINK_JOBS CMake variable to restrict the number of link jobs. IMO, a more thorough solution would be switching to LLD (the gold linker might work few years ago, but now even gold will take me nearly 16GB o...

Petr Hosek via llvm-dev <llvm-dev at lists.llvm.org> writes: > One of the design principles we're trying to follow is to make everything > read-only, unless it has be writable. The only reason for .dynamic to be > writable is DT_DEBUG which is something we never intend to support. FWIW in > Fuchsia all we need is a read-only .dynamic without emitting DT_DEBUG > altogether,

You can set the LLVM_PARALLEL_LINK_JOBS CMake variable to restrict the number of link jobs. On Sat, Aug 8, 2020 at 3:00 PM Neil Nelson via llvm-dev < llvm-dev at lists.llvm.org> wrote: > https://ninja-build.org/manual.html > > ninja -h prints help output. Many of Ninja’s flags intentionally match > those of Make; e.g ninja -C build -j 20 changes into the build directory >

> On Sep 24, 2020, at 23:52, Petr Hosek <phosek at chromium.org> wrote: > > Using more interface libraries is definitely the right direction and a modern way to use CMake. I'm not sure if we can get to a single interface target since different runtimes have different requirements. I was assuming that we would have one interface tar...

...ad set the -funwind-tables flag unconditionally using `add_compile_flags(-funwind-tables)` instead of `add_cxx_compile_flags_if_supported(-funwind-tables)`, everything is fine and the aforementioned bug is gone. I’ve found a PR which seemed to address this: https://reviews.llvm.org/D31858 (cc’ing @phosek, @compnerd and @beanz as participants of this PR). It mentions that the __aeabi_unwind_cpp_pr0 symbol is provided by the compiler runtime. However, as I’ve already said, it lives in libunwind, so the problem doesn’t seem to be solved. I’m very tempted to just set the -funwind-tables flag unconditi...

On Wed, May 17, 2017 at 1:32 PM, Rui Ueyama via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On Wed, May 17, 2017 at 1:11 PM, Petr Hosek <phosek at chromium.org> wrote: > >> The motivation is not only memory savings but also security: >> can-never-be-written is strictly better than RELRO in all cases. The >> biggest win is when .dynamic is the sole reason for having a writable >> segment at all. The distinction...

While trying to compile an existing codebase which uses handwritten assembly with LLVM, I ran into an issue around using backward references in assembly absolute expressions. A simple example can be the following snippet: _foo: .fill 0x100 _bar: .fill _bar - _foo _baz: .fill 0x100 While gas compiles this snippet without any errors, the integrated assembler throws an error: expected

...d-tables flag unconditionally using `add_compile_flags(-funwind-tables)` instead of `add_cxx_compile_flags_if_supported(-funwind-tables)`, everything is fine and the aforementioned bug is gone. >> >> I’ve found a PR which seemed to address this: https://reviews.llvm.org/D31858 (cc’ing @phosek, @compnerd and @beanz as participants of this PR). It mentions that the __aeabi_unwind_cpp_pr0 symbol is provided by the compiler runtime. However, as I’ve already said, it lives in libunwind, so the problem doesn’t seem to be solved. >> >> I’m very tempted to just set the -funwind-tab...

You also need -DLIBUNWIND_USE_COMPILER_RT=ON -DLIBCXXABI_USE_LLVM_UNWINDER=ON. This is because you set -DLIBCXXABI_USE_COMPILER_RT=ON so libc++abi.so is no longer being linked agains libgcc_s.so which is where the unwinder otherwise comes from. On Sun, May 6, 2018 at 4:05 AM via llvm-dev <llvm-dev at lists.llvm.org> wrote: > I try to compile LLVM, clang, lld and libcxx together in one

...d-tables flag unconditionally using `add_compile_flags(-funwind-tables)` instead of `add_cxx_compile_flags_if_supported(-funwind-tables)`, everything is fine and the aforementioned bug is gone. >> >> I’ve found a PR which seemed to address this: https://reviews.llvm.org/D31858 (cc’ing @phosek, @compnerd and @beanz as participants of this PR). It mentions that the __aeabi_unwind_cpp_pr0 symbol is provided by the compiler runtime. However, as I’ve already said, it lives in libunwind, so the problem doesn’t seem to be solved. >> >> I’m very tempted to just set the -funwind-tab...

On Fri, Jun 2, 2017 at 1: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++

I try to compile LLVM, clang, lld and libcxx together in one source directory following the instructions on the website. I'm running Arch Linux and already have LLVM, clang, lld and libcxx installed (prebuilt against libstdc++). Now I want a "pure" llvm toolchain. The following options were used: -DBOOTSTRAP_LLVM_ENABLE_LLD -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++

The usual workaround is to do `rm –rf .git/llvm-upstream-svn` and try again. You could also patch llvm/utils/git-svn/git-llvm to add the `--verbose` option to the `git apply` command, which would provide better diagnostic output. HTH, --paulr From: Petr Hosek [mailto:phosek at chromium.org] Sent: Wednesday, January 30, 2019 10:52 PM To: Robinson, Paul Cc: James Y Knight; llvm-dev; vedant_kumar at apple.com Subject: Re: [llvm-dev] 'git llvm push' not working for me on Windows I just hit this failure as well. I've uploaded the log to https://reviews.llvm.or...

The motivation is not only memory savings but also security: can-never-be-written is strictly better than RELRO in all cases. The biggest win is when .dynamic is the sole reason for having a writable segment at all. The distinction is fairly small for exploitability, but not negligible. LLD already has several command-line options that are not supported by or are different from ld or gold, so

Hi! I sometimes build LLVM with a static libc++.a in MacOS, so that I use the LLVM libc++ instead of the system-wide one. However, when doing so, I always get link errors when building LLVM, because the build system links with libc++.a, but not with libc++abi.a and so there are quite a few missing symbols that the linker cannot find. My workaround (which always seems to work) is to embed

...ionne at apple.com> on behalf of Louis Dionne <ldionne at apple.com> Date: Thursday, April 2, 2020 at 7:20 AM To: Shoaib Meenai <smeenai at fb.com> Cc: "llvm-dev at lists.llvm.org" <llvm-dev at lists.llvm.org>, Chris Bieneman <beanz at apple.com>, Petr Hosek <phosek at chromium.org>, Saleem Abdulrasool <compnerd at compnerd.org>, "tstellar at redhat.com" <tstellar at redhat.com> Subject: Re: Upgrading LLVM's minimum required CMake version Okay, so we've had some discussion on this thread, and although some people (including me...

...d-tables flag unconditionally using `add_compile_flags(-funwind-tables)` instead of `add_cxx_compile_flags_if_supported(-funwind-tables)`, everything is fine and the aforementioned bug is gone. >> >> I’ve found a PR which seemed to address this: https://reviews.llvm.org/D31858 (cc’ing @phosek, @compnerd and @beanz as participants of this PR). It mentions that the __aeabi_unwind_cpp_pr0 symbol is provided by the compiler runtime. However, as I’ve already said, it lives in libunwind, so the problem doesn’t seem to be solved. >> >> I’m very tempted to just set the -funwind-tab...

...t;> > *Cc: *"llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>" > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>>, Chris > Bieneman <beanz at apple.com <mailto:beanz at apple.com>>, Petr Hosek > <phosek at chromium.org <mailto:phosek at chromium.org>>, Saleem > Abdulrasool <compnerd at compnerd.org > <mailto:compnerd at compnerd.org>>, "tstellar at redhat.com > <mailto:tstellar at redhat.com>" <tstellar at redhat.com > <mailto:...

...i at fb.com<mailto:smeenai at fb.com>> Cc: "llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>" <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>>, Chris Bieneman <beanz at apple.com<mailto:beanz at apple.com>>, Petr Hosek <phosek at chromium.org<mailto:phosek at chromium.org>>, Saleem Abdulrasool <compnerd at compnerd.org<mailto:compnerd at compnerd.org>>, "tstellar at redhat.com<mailto:tstellar at redhat.com>" <tstellar at redhat.com<mailto:tstellar at redhat.com>> Subject:...