summaryrefslogtreecommitdiffstats
path: root/clang/lib/Driver/ToolChains/OpenBSD.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Default to -fuse-init-arrayFangrui Song2019-12-121-0/+9
| | | | | | | | | | | | | | | | | | | 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
* [Clang] Migrate llvm::make_unique to std::make_uniqueJonas Devlieghere2019-08-141-2/+2
| | | | | | | | | | 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
* Remove sanitizer context workaround no longer necessaryBrad Smith2019-02-231-3/+1
| | | | | | The base linker is now lld. llvm-svn: 354721
* [Driver] Don't pass default value to getCompilerRTArgStringPetr Hosek2019-01-211-2/+2
| | | | | | | | Using static library is already a default. Differential Revision: https://reviews.llvm.org/D56043 llvm-svn: 351710
* 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
* Reapply Pass the nopie flag to the linker when linking with -pg.Brad Smith2018-10-281-1/+1
| | | | llvm-svn: 345470
* Revert "Pass the nopie flag to the linker when linking with -pg." untilBrad Smith2018-10-271-1/+1
| | | | | | one of the tests can be fixed on !OpenBSD hosts. llvm-svn: 345443
* Pass the nopie flag to the linker when linking with -pg.Brad Smith2018-10-271-1/+1
| | | | llvm-svn: 345439
* Some improvements to the OpenBSD driver.Brad Smith2018-10-111-34/+30
| | | | | | | | - OpenBSD has switched to compiler_rt / libcxx - Fix sysroot and lib path handling - Some cleaning up llvm-svn: 344257
* OpenBSD driver needs ld.lld in sanitizer contextDavid Carlier2018-06-281-1/+3
| | | | | | | | | | | | | Base GNU ld is pretty ancient and does not support --dynamic-list flag. For conveniency, we can it automatically when compile with ubsan sanitizer flag. Reviewers: dberris Reviewed by: dberris Differential Revision: https://reviews.llvm.org/D48574 llvm-svn: 335856
* Use Triple::isMIPS() instead of enumerating all Triples. NFCAlexander Richardson2018-06-251-3/+3
| | | | | | | | Reviewed By: atanasyan Differential Revision: https://reviews.llvm.org/D48549 llvm-svn: 335495
* OpenBSD add C++ runtime in a driver's standpointDean Michael Berris2018-04-191-0/+8
| | | | | | | | | | | | | | Summary: - Since 6.2 release, on supporters platforms clang is shipped with both libcxx and libcxxabi. Reviewers: dberris, alekseyshl, EricWF Reviewed By: dberris Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D45662 llvm-svn: 330310
* Adding fuzzer flags support to OpenBSD driverDean Michael Berris2018-04-111-1/+4
| | | | | | | | | | | | | | Summary: - Following-up the sanitizer's part commit https://reviews.llvm.org/rCRT329631, we enable fuzzer flags. Reviewers: brad, thakis, dberris Reviewed By: dberris Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D44878 llvm-svn: 329779
* [XRay][clang] Consolidate runtime and link-time flag processing (NFC)Dean Michael Berris2018-04-061-24/+1
| | | | | | | | | | | | | | | | | | | Summary: This change fixes http://llvm.org/PR36985 to define a single place in CommonArgs.{h,cpp} where XRay runtime flags and link-time dependencies are processed for all toolchains that support XRay instrumentation. This is a refactoring of the same functionality spread across multiple toolchain definitions. Reviewers: echristo, devnexen, eizan Reviewed By: eizan Subscribers: emaste, cfe-commits Differential Revision: https://reviews.llvm.org/D45243 llvm-svn: 329372
* [XRay][clang] Allow clang to build XRay instrumented binaries in OpenBSDDean Michael Berris2018-04-041-0/+28
| | | | | | | | | | | | | | | | | | | Summary: This patch was originally reviewed in D45126. It enables clang to add the XRay runtime and the link-time dependencies for XRay instrumentation in OpenBSD. Landing for devnexen. Reviewers: brad, dberris Subscribers: dberris, krytarowski, cfe-commits Author: devnexen Differential Revision: https://reviews.llvm.org/D45126 llvm-svn: 329183
* OpenBSD Driver basic sanitiser supportKamil Rytarowski2018-03-031-1/+22
| | | | | | | | | | | | | | | | | | Summary: Basic support of Sanitiser to follow-up ubsan support in compiler-rt. Needs to use lld instead of base ld to be fully workable. Patch by: David CARLIER Reviewers: krytarowski, vitalybuka, kettenis Reviewed By: vitalybuka Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D43961 llvm-svn: 326648
* Also pass -pie back to the linker when linking on OpenBSD.Brad Smith2017-07-301-0/+2
| | | | llvm-svn: 309523
* Introduce -nostdlib++ flag to disable linking the C++ standard library.Nico Weber2017-07-251-1/+2
| | | | | | | | | | | | | | | 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] Consolidate tools and toolchains by target platform. (NFC)David L. Jones2017-03-081-0/+234
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