summaryrefslogtreecommitdiffstats
path: root/clang/lib/Driver/ToolChains/FreeBSD.h
Commit message (Collapse)AuthorAgeFilesLines
* Restore functionality of --sysroot on FreeBSD after b18cb9c47Dimitry Andric2020-02-191-5/+7
| | | | | | | | | | | | | | | | | After b18cb9c47, clang would sometimes prefer the host C++ includes (e.g. in /usr/include/c++/v1) before those specified via --sysroot. While this behavior may be desirable on Linux, it is not so on FreeBSD, where we make extensive use of --sysroot during the build of the base system. In that case, clang must *not* search outside the sysroot, except for its own internal headers. Add an override addLibCxxIncludePaths() to restore the old behavior, which is to simply append /usr/include/c++/v1 to the specified sysroot. While here, apply clang-format to the FreeBSD specific toolchain files. Fixes PR44923. (cherry picked from commit 62654cab7e654384ba503d6b62b1054cde19a553)
* [Driver] Use .init_array for all gcc installations and simplify Generic_ELF ↵Fangrui Song2019-12-131-0/+4
| | | | | | | | | | | | | | | | | -fno-use-init-array rules D39317 made clang use .init_array when no gcc installations is found. This change changes all gcc installations to use .init_array . GCC 4.7 by default stopped providing .ctors/.dtors compatible crt files, and stopped emitting .ctors for __attribute__((constructor)). .init_array should always work. FreeBSD rules are moved to FreeBSD.cpp to make Generic_ELF rules clean. Reviewed By: rnk Differential Revision: https://reviews.llvm.org/D71434
* Populate CUDA flags on FreeBSD too, as many other toolchains do.Dimitry Andric2019-11-181-0/+2
| | | | | | | | | | | | | | | | Summary: This allows `clang` to be used to compile CUDA programs. Compiled simple helloworld.cu with this. Reviewers: dim, emaste, tra, yaxunl, ABataev Reviewed By: tra Subscribers: dim, emaste, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D69990
* clang: enable unwind tables on FreeBSD !amd64Ed Maste2019-11-151-0/+1
| | | | | | | | | | | | | | | | | | | There doesn't seem to be much sense in defaulting "on" unwind tables on amd64 and not on other arches. It causes surprising differences between platforms, such as the PR below[1]. Prior to this change, FreeBSD inherited the default implementation of the method from the Gnu.h Generic_Elf => Generic_GCC parent class, which returned true only for amd64 targets. Override that and opt on always, similar to, e.g., NetBSD's driver. [1] https://bugs.freebsd.org/241562 Patch by cem (Conrad Meyer). Reviewed By: dim Differential Revision: https://reviews.llvm.org/D70110
* clang: default to DWARF 4 for FreeBSD 12.0 and laterEd Maste2019-09-031-1/+1
| | | | | | | | | | | | Older FreeBSD versions included GDB 6.1 and had other tools that were unable to handle debug information newer than DWARF 2. Those tools have since been updated. (An old version of GDB is still kept for kernel crash handling, but the kernel is compiled with an explicit -gdwarf2.) Reviewed by: dim Differential Revision: https://reviews.llvm.org/D66760 llvm-svn: 370779
* 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
* Toolchain: Normalize dwarf, sjlj and seh ehMartell Malone2017-11-291-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a re-apply of r319294. adds -fseh-exceptions and -fdwarf-exceptions flags clang will check if the user has specified an exception model flag, in the absense of specifying the exception model clang will then check the driver default and append the model flag for that target to cc1 -fno-exceptions has a higher priority then specifying the model move __SEH__ macro definitions out of Targets into InitPreprocessor behind the -fseh-exceptions flag move __ARM_DWARF_EH__ macrodefinitions out of verious targets and into InitPreprocessor behind the -fdwarf-exceptions flag and arm|thumb check remove unused USESEHExceptions from the MinGW Driver fold USESjLjExceptions into a new GetExceptionModel function that gives the toolchain classes more flexibility with eh models Reviewers: rnk, mstorsjo Differential Revision: https://reviews.llvm.org/D39673 llvm-svn: 319297
* Revert "Toolchain: Normalize dwarf, sjlj and seh eh"Martell Malone2017-11-291-2/+1
| | | | | | | | This reverts rL319294. The windows sanitizer does not like seh on x86. Will re apply with None type for x86 llvm-svn: 319295
* Toolchain: Normalize dwarf, sjlj and seh ehMartell Malone2017-11-291-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | adds -fseh-exceptions and -fdwarf-exceptions flags clang will check if the user has specified an exception model flag, in the absense of specifying the exception model clang will then check the driver default and append the model flag for that target to cc1 clang cc1 assumes dwarf is the default if none is passed and -fno-exceptions has a higher priority then specifying the model move __SEH__ macro definitions out of Targets into InitPreprocessor behind the -fseh-exceptions flag move __ARM_DWARF_EH__ macrodefinitions out of verious targets and into InitPreprocessor behind the -fdwarf-exceptions flag and arm|thumb check remove unused USESEHExceptions from the MinGW Driver fold USESjLjExceptions into a new GetExceptionModel function that gives the toolchain classes more flexibility with eh models Reviewers: rnk, mstorsjo Differential Revision: https://reviews.llvm.org/D39673 llvm-svn: 319294
* [Driver] Consolidate tools and toolchains by target platform. (NFC)David L. Jones2017-03-081-0/+86
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