similar to: [CMake] CMAKE_TOOLCHAIN_FILE and projects

I can build llvm and associated tools in a 1 shot go using gcc and g++ but trying to use only gcc and bootstrap clang to build and link with libc++ and libc++abi on the second phase of the build, the compilation fails I have svn cloned LLVM CLANG CLANG_XTRA_TOOLS LLD LLDB POLLY COMPILER_RT OPENMP LIBCXX LIBCXXABI cmake command below cmake -DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_ASSERTIONS=OFF

LLVM already implements its own version of almost all of binutils. The exceptions to this rule are objcopy and strip. This is a proposal to implement an llvm version of objcopy/strip to complete llvm’s binutils. Several projects only use gnu binutils because of objcopy/strip. LLVM itself uses objcopy in fact. Chromium and Fuchsia currently use objcopy as well. If you want to distribute your build

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

Hello, When I try to use -fprofile-instr-generate with clang (which is built from source) I am getting following error : ld: file not found: /Users/Mr.Pandya/My_Stuff/Active/llvm/build/bin/../lib/clang/3.9.0/lib/darwin/libclang_rt.profile_osx.a clang-3.9: error: linker command failed with exit code 1 (use -v to see invocation) I am not building compiler RT with LLVM. Am I missing any thing

Hi Jake. Thanks for the info. Where can I keep up to date on the symbolizer status? Our symbolizer is provided by the Myriad vendor and integrated into its host test environment. It doesn't do much: just look for PC string patterns and symbolize them using addr2line. Thanks, Walter On Fri, May 4, 2018 at 5:36 PM Jake Ehrlich <jakehehrlich at google.com> wrote: > Hey, > I

On 6/1/15 6:42 PM, Chris Bieneman wrote: > Looping in cfe-dev because I should have send this there too from the > start. > > -Chris > >> On Jun 1, 2015, at 3:21 PM, Chris Bieneman <beanz at apple.com> >> wrote: >> >> LLVMDev, >> >> PR 15732 is the umbrella tracking the progress of making the CMake >> build system feature equivalent to

I have ported ASan in LLVM to Myriad RTEMS, and I would like to upstream the port. Below is the design doc. Feedback welcome. https://docs.google.com/document/d/1oxmk0xUojybDaQDAuTEVpHVMi5xQX74cJPyMJbaSaRM The port is expected to work with modified versions of RTEMS and newlib. I have a git repo with changes to those projects, that I can make available if there is interest. Here is the patch

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++

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

Hey, I work on fuchsia symbolizer stuff. I don't know if you guys already have an external symbolizer but I'm working on making one right now and I plan on making one backed by LLVM that can be run host-side or target-side. I'd like to contribute that back to llvm ideally. What do you guys have so far? I have a prototype in golang that just spins up an instance of llvm-symbolizer

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

So, we’ve had this conversation a few times, and I wanted to coalate a status report for all the interested parties. Here's the outstanding work and my (not necissarily correct) view of the status and importance of each one: * Bug 12157 - llvmconfig.cmake.in make cmake installations not relocatable - There are patches on the bug that we should review, test, and land * Bug 14109 - CMake

On 11 March 2015 at 13:06, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > So that we can drop autotools, which currently requires anyone wanting > to change the build to install an old version of autoconf, among other > pains. Having two build systems is a way bigger pain than someone > having to install cmake. Can you explain why we need to upgrade CMake to drop

Hi, On Tue, 6 Oct 2020 at 18:31, David Blaikie <dblaikie at gmail.com> wrote: > > My 2c would be to push back a bit more on the "let's not have a machine readable format, but instead parse the human readable format" - it seems like that's going to make the human readable format/parsing fairly brittle/hard to change (I mean, having the parser in tree will help, for

Your understanding is correct. It saves a small number of physical pages. It's strictly better even if it's only a little bit better. On Tue, May 16, 2017, 5:14 PM Rui Ueyama <ruiu at google.com> wrote: > Hi Jake, > > Thank you for sending this to llvm-dev! > > If I understand correctly, your motivation to add an option to make > .dynamic sections read-only is to

Hello all, LLVM-TAPI seeks to decouple the necessary link-time information for a dynamic shared object from the implementation of the runtime object. This process will be referred to as dynamic shared object (DSO) stubbing throughout this proposal. A number of projects have implemented their own versions of shared object stubbing for a variety of reasons related to improving the overall linking

What do you expect the support for Windows to be? Certainly, I don't expect you to provide Windows support personally if you don't need it, but given that LLVM supports Windows, it should at least be done in such a way that the design lends itself to interested parties contributing Windows support. Currently clang-cl has several dependencies on having a Visual Studio installation present

Greetings, compiler-rt hosts a hardened usermode memory allocator, named Scudo ( https://llvm.org/docs/ScudoHardenedAllocator.html). It aims at providing additional mitigation against heap-based vulnerabilities, while maintaining good performance. It leverages sanitizer_common code, and provides allocation primitives via the usual C/C++ functions. Up until now, Scudo was mostly used (as far as I

Since the goal is to start llvm-tapi more or less from scratch, I feel the best approach initially is to focus on the structure as a key point of feedback in initial reviews. Once the foundations are set, integrating Mach-O TAPI in parallel with the ELF implementation should be relatively straightforward. The features outside of stubbing aren't as appealing for ELF, so I probably won't be

Sorry for the late response. You should check out CMAKE_TOOLCHAIN_FILE logic for Android platform - IIRC build rules for Android are much simpler than for Darwin/Linux, and assume that build tree will be properly configured to build a single compiler-rt runtime for a specific triple. Probably this is the approach you want to eventually use for another platforms. Also check out