summaryrefslogtreecommitdiffstats
path: root/clang/lib/Driver/ToolChains/Fuchsia.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [Clang] Always set -z now linker option on FuchsiaPetr Hosek2020-01-131-0/+3
| | | | | | This should be the default on Fuchsia. Differential Revision: https://reviews.llvm.org/D70576
* Default to -fuse-init-arrayFangrui Song2019-12-121-3/+3
| | | | | | | | | | | | | | | | | | | Very few ELF platforms still use .ctors/.dtors now. Linux (glibc: 1999-07), DragonFlyBSD, FreeBSD (2012-03) and Solaris have supported .init_array for many years. Some architectures like AArch64/RISC-V default to .init_array . GNU ld and gold can even convert .ctors to .init_array . It makes more sense to flip the CC1 default, and only uses -fno-use-init-array on platforms that don't support .init_array . For example, OpenBSD did not support DT_INIT_ARRAY before Aug 2016 (https://github.com/openbsd/src/commit/86fa57a2792c6374b0849dd7b818a11e676e60ba) I may miss some ELF platforms that still use .ctors, but their maintainers can easily diagnose such problems. Reviewed By: rnk Differential Revision: https://reviews.llvm.org/D71393
* [Fuchsia] Don't fail for unknown architecturesPetr Hosek2019-11-261-3/+2
| | | | | | | | When selecting the set of default sanitizers, don't fail for unknown architectures. This may be the case e.g. with x86_64-unknown-fuchsia -m32 target that's used to build the bootloader. Differential Revision: https://reviews.llvm.org/D70747
* [Clang] Enable RISC-V support for FuchsiaPetr Hosek2019-11-211-3/+11
| | | | | | | | We don't have a full sysroot yet, so for now we only include compiler support and compiler-rt builtins, the rest of the runtimes will get enabled later. Differential Revision: https://reviews.llvm.org/D70477
* [Driver] Enable ShadowCallStack, not SafeStack, by default on AArch64 FuchsiaLeonard Chan2019-10-281-1/+6
| | | | | | | | | | | Submitted for mcgrathr. On AArch64, Fuchsia fully supports both SafeStack and ShadowCallStack ABIs. The latter is now preferred and will be the default. It's possible to enable both simultaneously, but ShadowCallStack is believed to have most of the practical benefit of SafeStack with less cost. Differential Revision: https://reviews.llvm.org/D66712
* [Driver] Always use -z separate-loadable-segments with lld on FuchsiaFangrui Song2019-09-251-1/+1
| | | | | | | | | | The option was added to lld in D67481/372807. Reviewed By: phosek Differential Revision: https://reviews.llvm.org/D68009 llvm-svn: 372814
* [Clang] Migrate llvm::make_unique to std::make_uniqueJonas Devlieghere2019-08-141-1/+1
| | | | | | | | | | Now that we've moved to C++14, we no longer need the llvm::make_unique implementation from STLExtras.h. This patch is a mechanical replacement of (hopefully) all the llvm::make_unique instances across the monorepo. Differential revision: https://reviews.llvm.org/D66259 llvm-svn: 368942
* [Driver] Always use -z separate-code with lld on FuchsiaPetr Hosek2019-08-051-0/+2
| | | | | | | Previously -z separate-code was the default lld behavior, but now it has to be explicitly requested by specifying the flag. llvm-svn: 367796
* [CMake][Fuchsia] Define asan+noexcept multilibPetr Hosek2019-07-131-0/+5
| | | | | | | | | | | | | | | | | | Using noexcept multilib with -fno-exceptions can lead to significant space savings when statically linking libc++abi because we don't need all the unwinding and demangling code. When compiling with ASan, we already get a lot of overhead from the instrumentation itself, when statically linking libc++abi, that overhead is even larger. Having the noexcept variant for ASan can help significantly, we've seen more than 50% size reduction in our system image, which offsets the cost of having to build another multilib. Differential Revision: https://reviews.llvm.org/D64140 llvm-svn: 365994
* [Driver] Update handling of c++ and runtime directoriesPetr Hosek2019-05-261-19/+14
| | | | | | | | | | | | This is a follow up to r361432 and r361504 which addresses issues introduced by those changes. Specifically, it avoids duplicating file and runtime paths in case when the effective triple is the same as the cannonical one. Furthermore, it fixes the broken multilib setup in the Fuchsia driver and deduplicates some of the code. Differential Revision: https://reviews.llvm.org/D62442 llvm-svn: 361709
* [runtimes] Move libunwind, libc++abi and libc++ to lib/$target/c++ and ↵Petr Hosek2019-05-221-2/+2
| | | | | | | | | | | | | | | | | include/c++ This change is a consequence of the discussion in "RFC: Place libs in Clang-dedicated directories", specifically the suggestion that libunwind, libc++abi and libc++ shouldn't be using Clang resource directory. Tools like clangd make this assumption, but this is currently not true for the LLVM_ENABLE_PER_TARGET_RUNTIME_DIR build. This change addresses that by moving the output of these libraries to lib/$target/c++ and include/c++ directories, leaving resource directory only for compiler-rt runtimes and Clang builtin headers. Differential Revision: https://reviews.llvm.org/D59168 llvm-svn: 361432
* [Fuchsia] Support multilib for -fsanitize=address and -fno-exceptionsPetr Hosek2019-04-271-2/+50
| | | | | | | | | | | | | | | This introduces a support for multilibs to Fuchsia driver. Unlike the existing multilibs that are used primarily for handling different architecture variants, we use multilibs to handle different variants of Clang runtime libraries: -fsanitize=address and -fno-exceptions are the two we support initially. This replaces the existing support for sanitized runtimes libraries that was only used by Fuchsia driver and it also refactors some of the logic to allow sharing between GNU and Fuchsia drivers. Differential Revision: https://reviews.llvm.org/D61040 llvm-svn: 359360
* [asan] Add gcc 8's driver option -fsanitize=pointer-compare and ↵Pierre Gousseau2019-04-121-0/+2
| | | | | | | | | | | | -fsanitize=pointer-substract. Disabled by default as this is still an experimental feature. Reviewed By: thakis Differential Revision: https://reviews.llvm.org/D59221 llvm-svn: 358285
* Revert "[runtimes] Move libunwind, libc++abi and libc++ to lib/ and include/"Matthew Voss2019-03-081-2/+2
| | | | | | | | This broke the windows bots. This reverts commit 28302c66d2586074f77497d5dc4eac7182b679e0. llvm-svn: 355725
* [runtimes] Move libunwind, libc++abi and libc++ to lib/ and include/Petr Hosek2019-03-081-2/+2
| | | | | | | | | | | | | | | This change is a consequence of the discussion in "RFC: Place libs in Clang-dedicated directories", specifically the suggestion that libunwind, libc++abi and libc++ shouldn't be using Clang resource directory. Tools like clangd make this assumption, but this is currently not true for the LLVM_ENABLE_PER_TARGET_RUNTIME_DIR build. This change addresses that by moving the output of these libraries to lib/<target> and include/ directories, leaving resource directory only for compiler-rt runtimes and Clang builtin headers. Differential Revision: https://reviews.llvm.org/D59013 llvm-svn: 355665
* [Driver][Fuchsia] Support -nolibc flagPetr Hosek2019-02-171-1/+2
| | | | | | | | | | | This can be used to disable libc linking. This flag is supported by GCC since version 9 as well as some Clang target toolchains. This change also includes tests for all -no* flags which previously weren't covered. Differential Revision: https://reviews.llvm.org/D58325 llvm-svn: 354208
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-4/+3
| | | | | | | | | | | | | | | | | to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
* [Driver] Support XRay on FuchsiaPetr Hosek2018-11-221-2/+6
| | | | | | | | This enables support for XRay in Fuchsia Clang driver. Differential Revision: https://reviews.llvm.org/D52160 llvm-svn: 347444
* [Driver] Link sanitizer runtime deps on Fuchsia when neededPetr Hosek2018-11-211-2/+4
| | | | | | | | | | Even though these deps weren't needed, this makes Fuchsia driver better match other drivers, and it may be necessary when trying to use different C libraries on Fuchsia. Differential Revision: https://reviews.llvm.org/D54741 llvm-svn: 347378
* [Driver] Use -Bstatic/dynamic for libc++ on FuchsiaPetr Hosek2018-11-041-1/+3
| | | | | | | | | -static relies on lld's behavior, but -Bstatic/dynamic is supported across all linkers. Differential Revision: https://reviews.llvm.org/D54082 llvm-svn: 346107
* [Driver] Use -push-/-pop-state and -as-needed for libc++ on FuchsiaPetr Hosek2018-11-031-4/+5
| | | | | | | | | | This avoids introducing unnecessary DT_NEEDED entries when using C++ driver for linking C code or C++ code that doesn't use C++ standard library. Differential Revision: https://reviews.llvm.org/D53854 llvm-svn: 346064
* [Driver] Support sanitized libraries on FuchsiaPetr Hosek2018-10-291-2/+5
| | | | | | | | | | When using sanitizers, add <resource_dir>/<target>/lib/<sanitizer> to the list of library paths to support using sanitized version of runtime libraries if available. Differential Revision: https://reviews.llvm.org/D53487 llvm-svn: 345537
* [profile] Support profiling runtime on FuchsiaPetr Hosek2018-07-251-0/+1
| | | | | | | | | | | | | This ports the profiling runtime on Fuchsia and enables the instrumentation. Unlike on other platforms, Fuchsia doesn't use files to dump the instrumentation data since on Fuchsia, filesystem may not be accessible to the instrumented process. We instead use the data sink to pass the profiling data to the system the same sanitizer runtimes do. Differential Revision: https://reviews.llvm.org/D47208 llvm-svn: 337881
* Support for multiarch runtimes layoutPetr Hosek2018-06-281-22/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | This change adds a support for multiarch style runtimes layout, so in addition to the existing layout where runtimes get installed to: lib/clang/$version/lib/$os Clang now allows runtimes to be installed to: lib/clang/$version/$target/lib This also includes libc++, libc++abi and libunwind; today those are assumed to be in Clang library directory built for host, with the new layout it is possible to install libc++, libc++abi and libunwind into the runtime directory built for different targets. The use of new layout is enabled by setting the LLVM_ENABLE_RUNTIME_TARGET_DIR CMake variable and is supported by both projects and runtimes layouts. The runtimes CMake build has been further modified to use the new layout when building runtimes for multiple targets. Differential Revision: https://reviews.llvm.org/D45604 llvm-svn: 335809
* [Fuchsia] Enable static libc++, libc++abi, libunwindPetr Hosek2018-06-231-1/+8
| | | | | | | | This is needed for building Fuchsia drivers. Differential Revision: https://reviews.llvm.org/D48208 llvm-svn: 335410
* [Driver][Fuchsia] Pass LTO flags to linkerPetr Hosek2018-06-051-0/+6
| | | | | | | | | Even though we use lld by default for Fuchsia, we use Gold plugin arguments like all other drivers as lld supports Gold plugin options. Differential Revision: https://reviews.llvm.org/D47668 llvm-svn: 333979
* [Driver] Only use -lc++ on FuchsiaPetr Hosek2018-05-111-2/+0
| | | | | | | | | The fact that libc++ depends on libc++abi and libunwind is an internal detail that's captured by the libc++.so linker script. Differential Revision: https://reviews.llvm.org/D46768 llvm-svn: 332138
* [Driver] Add fuzzer-no-link into the list of supported Fuchsia sanitizersPetr Hosek2018-03-271-0/+1
| | | | | | | | This is needed in addition to fuzzer in order to use libFuzzer. Differential Revision: https://reviews.llvm.org/D44947 llvm-svn: 328672
* [Driver] Enable SafeStack by default on FuchsiaPetr Hosek2018-03-071-0/+4
| | | | | | | | This is already used throughout the entire system, so make it a default. Differential Revision: https://reviews.llvm.org/D44065 llvm-svn: 326867
* [Fuchsia] Enable Fuzzer as a supported sanitizer on FuchsiaPetr Hosek2018-01-191-1/+2
| | | | | | | | libFuzzer has been ported to Fuchsia so enable it in the driver. Differential Revision: https://reviews.llvm.org/D42275 llvm-svn: 322916
* [scudo] Add -fsanitize=scudo option to FuchsiaPetr Hosek2017-12-211-0/+1
| | | | | | | | | | | | | | Apparently the -fsanitize flag hadn't been added for Scudo upstream yet. Patch By: flowerhack Reviewers: cryptoad, alekseyshl, mcgrathr, phosek Reviewed By: mcgrathr, phosek Differential Revision: https://reviews.llvm.org/D41413 llvm-svn: 321314
* [Driver] Use ld.lld directly for Fuchsia rather than passing flavorPetr Hosek2017-10-231-4/+2
| | | | | | | | | | | Passing a flavor to LLD requires command line argument, but if these are being passed through a response file, this will fail because LLD needs to know which driver to use before processing the response file. Use ld.lld directly instead to avoid this issue. Differential Revision: https://reviews.llvm.org/D39176 llvm-svn: 316379
* Cleanup and generalize -shared-libasan.Evgeniy Stepanov2017-10-051-1/+1
| | | | | | | | | | | | | | | | | | | | Summary: * Rename -shared-libasan to -shared-libsan, keeping the old name as alias. * Add -static-libsan for targets that default to shared. * Remove an Android special case. It is now possible (but untested) to use static compiler-rt libraries there. * Support libclang_rt.ubsan_standalone as a shared library. Unlike GCC, this change applies -shared-libsan / -static-libsan to all sanitizers. I don't see a point in multiple flags like -shared-libubsan, considering that most sanitizers are not compatible with each other, and each link has basically a single shared/static choice. Reviewers: vitalybuka, kcc, rsmith Subscribers: srhines, cfe-commits Differential Revision: https://reviews.llvm.org/D38525 llvm-svn: 315015
* [Driver][Fuchsia] Pass --hash-style=gnu to the linkerPetr Hosek2017-08-041-2/+4
| | | | | | | | | The .gnu_hash format is superior, and all versions of the Fuchsia dynamic linker support it. Differential Revision: https://reviews.llvm.org/D36254 llvm-svn: 310017
* Enable AddressSanitizer for Fuchsia targetsPetr Hosek2017-08-031-10/+13
| | | | | | | | Patch by Roland McGrath Differential Revision: https://reviews.llvm.org/D35922 llvm-svn: 309999
* [Driver] Disable static C++ library support on FuchsiaPetr Hosek2017-08-021-8/+1
| | | | | | | | Don't support or build static C++ libraries for Fuchsia. Differential Revision: https://reviews.llvm.org/D36202 llvm-svn: 309778
* Introduce -nostdlib++ flag to disable linking the C++ standard library.Nico Weber2017-07-251-7/+9
| | | | | | | | | | | | | | | Projects that want to statically link their own C++ standard library currently need to pass -nostdlib or -nodefaultlibs, which also disables linking of the builtins library, -lm, and so on. Alternatively, they could use `clang` instead of `clang++`, but that already disables implicit addition of -lm on some toolchains. Add a dedicated flag -nostdlib++ that disables just linking of libc++ / libstdc++. This is analogous to -nostdinc++. https://reviews.llvm.org/D35780 llvm-svn: 308997
* [Driver] Always use -z rodynamic for FuchsiaPetr Hosek2017-07-181-0/+3
| | | | | | | | Fuchsia uses read-only .dynamic section. Differential Revision: https://reviews.llvm.org/D35582 llvm-svn: 308390
* Reland "[Driver] Update Fuchsia driver path handling"Petr Hosek2017-07-121-13/+66
| | | | | | | | | | | | | | | | | Several improvements to the Fuchsia driver: * Search for C++ library headers and libraries in directories that are part of the toolchain distribution rather than sysroot. * Use LLVM support utlities to construct paths to make sure the driver is also usable on Windows for cross-compiling. * Change the driver to inherit directly from ToolChain rather than Generic_GCC since we don't need any of the GCC related multilib logic. Differential Revision: https://reviews.llvm.org/D35328 llvm-svn: 307856
* Revert "[Driver] Update Fuchsia driver path handling"Petr Hosek2017-07-121-66/+13
| | | | | | | | The tests are failing on Windows. This reverts commit 429fe8229496f639df6b0b4734beedb1d4317aa5. llvm-svn: 307845
* [Driver] Update Fuchsia driver path handlingPetr Hosek2017-07-121-13/+66
| | | | | | | | | | | | | | | | | Several improvements to the Fuchsia driver: * Search for C++ library headers and libraries in directories that are part of the toolchain distribution rather than sysroot. * Use LLVM support utlities to construct paths to make sure the driver is also usable on Windows for cross-compiling. * Change the driver to inherit directly from ToolChain rather than Generic_GCC since we don't need any of the GCC related multilib logic. Differential Revision: https://reviews.llvm.org/D32613 llvm-svn: 307830
* [OpenMP] Extend CLANG target options with device offloading kind.Gheorghe-Teodor Bercea2017-07-061-1/+2
| | | | | | | | | | | | | | Summary: Pass the type of the device offloading when building the tool chain for a particular target architecture. This is required when supporting multiple tool chains that target a single device type. In our particular use case, the OpenMP and CUDA tool chains will use the same ```addClangTargetOptions ``` method. This enables the reuse of common options and ensures control over options only supported by a particular tool chain. Reviewers: arpith-jacob, caomhin, carlo.bertolli, ABataev, jlebar, hfinkel, tstellar, Hahnfeld Reviewed By: hfinkel Subscribers: jgravelle-google, aheejin, rengolin, jfb, dschuff, sbc100, cfe-commits Differential Revision: https://reviews.llvm.org/D29647 llvm-svn: 307272
* [Driver] Consolidate tools and toolchains by target platform. (NFC)David L. Jones2017-03-081-0/+229
Summary: (This is a move-only refactoring patch. There are no functionality changes.) This patch splits apart the Clang driver's tool and toolchain implementation files. Each target platform toolchain is moved to its own file, along with the closest-related tools. Each target platform toolchain has separate headers and implementation files, so the hierarchy of classes is unchanged. There are some remaining shared free functions, mostly from Tools.cpp. Several of these move to their own architecture-specific files, similar to r296056. Some of them are only used by a single target platform; since the tools and toolchains are now together, some helpers now live in a platform-specific file. The balance are helpers related to manipulating argument lists, so they are now in a new file pair, CommonArgs.h and .cpp. I've tried to cluster the code logically, which is fairly straightforward for most of the target platforms and shared architectures. I think I've made reasonable choices for these, as well as the various shared helpers; but of course, I'm happy to hear feedback in the review. There are some particular things I don't like about this patch, but haven't been able to find a better overall solution. The first is the proliferation of files: there are several files that are tiny because the toolchain is not very different from its base (usually the Gnu tools/toolchain). I think this is mostly a reflection of the true complexity, though, so it may not be "fixable" in any reasonable sense. The second thing I don't like are the includes like "../Something.h". I've avoided this largely by clustering into the current file structure. However, a few of these includes remain, and in those cases it doesn't make sense to me to sink an existing file any deeper. Reviewers: rsmith, mehdi_amini, compnerd, rnk, javed.absar Subscribers: emaste, jfb, danalbert, srhines, dschuff, jyknight, nemanjai, nhaehnle, mgorny, cfe-commits Differential Revision: https://reviews.llvm.org/D30372 llvm-svn: 297250
OpenPOWER on IntegriCloud