#
d0b2dbfa |
|
16-Aug-2023 |
Warner Losh <imp@FreeBSD.org> |
Remove $FreeBSD$: one-line sh pattern Remove /^\s*#[#!]?\s*\$FreeBSD\$.*$\n/
|
#
81ad6265 |
|
04-Jul-2022 |
Dimitry Andric <dim@FreeBSD.org> |
Merge llvm-project main llvmorg-15-init-15358-g53dc0f10787 This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp to llvmorg-15-init-15358-g53dc0f10787. PR: 265425 MFC after: 2 weeks
|
#
fe6060f1 |
|
22-Aug-2021 |
Dimitry Andric <dim@FreeBSD.org> |
Merge llvm-project main llvmorg-13-init-16847-g88e66fa60ae5 This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp to llvmorg-13-init-16847-g88e66fa60ae5, the last commit before the upstream release/13.x branch was created. PR: 258209 MFC after: 2 weeks
|
#
e8d8bef9 |
|
13-Jun-2021 |
Dimitry Andric <dim@FreeBSD.org> |
Merge llvm-project main llvmorg-12-init-17869-g8e464dd76bef This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp to llvmorg-12-init-17869-g8e464dd76bef, the last commit before the upstream release/12.x branch was created. PR: 255570 MFC after: 6 weeks
|
#
48aaf27b |
|
06-Aug-2020 |
Dimitry Andric <dim@FreeBSD.org> |
Update Makefiles under lib/clang and usr.bin/clang for 11.0.0 builds, and also bump the version in the mtree files. |
#
38b6f456 |
|
25-Jan-2020 |
Dimitry Andric <dim@FreeBSD.org> |
Adjust libllvmminimal and tblgen Makefiles so all the tblgen executables build. |
#
0b57cec5 |
|
20-Dec-2019 |
Dimitry Andric <dim@FreeBSD.org> |
Move all sources from the llvm project into contrib/llvm-project. This uses the new layout of the upstream repository, which was recently migrated to GitHub, and converted into a "monorepo". That is, most of the earlier separate sub-projects with their own branches and tags were consolidated into one top-level directory, and are now branched and tagged together. Updating the vendor area to match this layout is next. |
#
4014a71f |
|
23-Aug-2019 |
Dimitry Andric <dim@FreeBSD.org> |
Update build glue for a minimal build of the clang executable. |
#
36cb3905 |
|
21-Dec-2017 |
Dimitry Andric <dim@FreeBSD.org> |
First step in updating llvm/clang build glue: make only the clang executable build. |
#
5897d2f0 |
|
17-Apr-2017 |
Dimitry Andric <dim@FreeBSD.org> |
Initial update of clang/llvm build glue, for building just a minimal clang executable. |
#
986e05bc |
|
26-Aug-2016 |
Dimitry Andric <dim@FreeBSD.org> |
Completely revamp the way llvm, clang and lldb are built. * Bootstrap llvm-tblgen and clang-tblgen with a minimal llvm static library, that has no other dependencies. * Roll up all separate llvm libraries into one big static libllvm. * Similar for all separate clang and lldb static libraries. * For all these libraries, generate their .inc files only once. * Link all llvm tools (including extra) against the big libllvm. * Link clang and clang-format against the big libllvm and libclang. * Link lldb against the big libllvm, libclang and liblldb. N.B.: This is work in progress, some details may still be missing. It also heavily depends on bsd.*.mk's support for SRCS and DPSRCS with relative pathnames, which apparently does not always work as expected. For building llvm, clang and lldb though, it seems to work just fine. The main idea behind this restructuring is maintainability and build peformance. The previous large number of very small libraries, each with their own generated files and dependencies was slow to traverse and hard to understand. Possible future improvements: * Only build certain targets, e.g. for most regular users having just one target will be fine. This will shave off some build time. * Building the big llvm, clang and lldb libraries as shared (private) libraries. * Adding other components from the LLVM project, such as lld. |
#
5608fd23 |
|
19-Aug-2014 |
Bryan Drewery <bdrewery@FreeBSD.org> |
Revert r267233 for now. PIE support needs to be reworked. 1. 50+% of NO_PIE use is fixed by adding -fPIC to INTERNALLIB and other build-only utility libraries. 2. Another 40% is fixed by generating _pic.a variants of various libraries. 3. Some of the NO_PIE use is a bit absurd as it is disabling PIE (and ASLR) where it never would work anyhow, such as csu or loader. This suggests there may be better ways of adding support to the tree. Many of these cases can be fixed such that -fPIE will work but there is really no reason to have it in those cases. 4. Some of the uses are working around hacks done to some Makefiles that are really building libraries but have been using bsd.prog.mk because the code is cleaner. Had they been using bsd.lib.mk then NO_PIE would not have been needed. We likely do want to enable PIE by default (opt-out) for non-tree consumers (such as ports). For in-tree though we probably want to only enable PIE (opt-in) for common attack targets such as remote service daemons and setuid utilities. This is also a great performance compromise since ASLR is expected to reduce performance. As such it does not make sense to enable it in all utilities such as ls(1) that have little benefit to having it enabled. Reported by: kib |
#
864c53ea |
|
08-Jun-2014 |
Bryan Drewery <bdrewery@FreeBSD.org> |
In preparation for ASLR [1] support add WITH_PIE to support building with -fPIE. This is currently an opt-in build flag. Once ASLR support is ready and stable it should changed to opt-out and be enabled by default along with ASLR. Each application Makefile uses opt-out to ensure that ASLR will be enabled by default in new directories when the system is compiled with PIE/ASLR. [2] Mark known build failures as NO_PIE for now. The only known runtime failure was rtld. [1] http://www.bsdcan.org/2014/schedule/events/452.en.html Submitted by: Shawn Webb <lattera@gmail.com> Discussed between: des@ and Shawn Webb [2] |
#
3bdf7758 |
|
12-Apr-2014 |
Warner Losh <imp@FreeBSD.org> |
NO_MAN= has been deprecated in favor of MAN= for some time, go ahead and finish the job. ncurses is now the only Makefile in the tree that uses it since it wasn't a simple mechanical change, and will be addressed in a future commit. |
#
f785676f |
|
16-Feb-2014 |
Dimitry Andric <dim@FreeBSD.org> |
Upgrade our copy of llvm/clang to 3.4 release. This version supports all of the features in the current working draft of the upcoming C++ standard, provisionally named C++1y. The code generator's performance is greatly increased, and the loop auto-vectorizer is now enabled at -Os and -O2 in addition to -O3. The PowerPC backend has made several major improvements to code generation quality and compile time, and the X86, SPARC, ARM32, Aarch64 and SystemZ backends have all seen major feature work. Release notes for llvm and clang can be found here: <http://llvm.org/releases/3.4/docs/ReleaseNotes.html> <http://llvm.org/releases/3.4/tools/clang/docs/ReleaseNotes.html> MFC after: 1 month
|
#
139f7f9b |
|
12-Apr-2013 |
Dimitry Andric <dim@FreeBSD.org> |
Upgrade our copy of llvm/clang to trunk r178860, in preparation of the upcoming 3.3 release (branching and freezing expected in a few weeks). Preliminary release notes can be found at the usual location: <http://llvm.org/docs/ReleaseNotes.html> An MFC is planned once the actual 3.3 release is finished.
|
#
8a166caf |
|
11-Feb-2013 |
Andrew Turner <andrew@FreeBSD.org> |
Allow us to build clang for ARM EABI. Clang and llvm use the arm-gnueabi-freebsd10.0 triple for EABI. Use this when we are on arm or armv6 and are building for EABI. Reviewed by: dim |
#
3861d79f |
|
03-Dec-2012 |
Dimitry Andric <dim@FreeBSD.org> |
Upgrade our copy of llvm/clang to r168974, from upstream's release_32 branch. This is effectively llvm/clang 3.2 RC2; the 3.2 release is coming soon.
|
#
7ae0e2c9 |
|
20-Aug-2012 |
Dimitry Andric <dim@FreeBSD.org> |
Upgrade our copy of llvm/clang to trunk r162107. With thanks to Benjamin Kramer and Joerg Sonnenberger for their input and fixes.
|
#
6122f3e6 |
|
22-Oct-2011 |
Dimitry Andric <dim@FreeBSD.org> |
Upgrade our copy of llvm/clang to r142614, from upstream's release_30 branch. This brings us very close to the 3.0 release, which is expected in a week or two. MFC after: 1 week
|
#
fe6060f1 |
|
22-Aug-2021 |
Dimitry Andric <dim@FreeBSD.org> |
Merge llvm-project main llvmorg-13-init-16847-g88e66fa60ae5 This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp to llvmorg-13-init-16847-g88e66fa60ae5, the last commit before the upstream release/13.x branch was created. PR: 258209 MFC after: 2 weeks
|
#
e8d8bef9 |
|
13-Jun-2021 |
Dimitry Andric <dim@FreeBSD.org> |
Merge llvm-project main llvmorg-12-init-17869-g8e464dd76bef This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp to llvmorg-12-init-17869-g8e464dd76bef, the last commit before the upstream release/12.x branch was created. PR: 255570 MFC after: 6 weeks
|
#
48aaf27b |
|
06-Aug-2020 |
Dimitry Andric <dim@FreeBSD.org> |
Update Makefiles under lib/clang and usr.bin/clang for 11.0.0 builds, and also bump the version in the mtree files. |
#
38b6f456 |
|
25-Jan-2020 |
Dimitry Andric <dim@FreeBSD.org> |
Adjust libllvmminimal and tblgen Makefiles so all the tblgen executables build. |
#
0b57cec5 |
|
20-Dec-2019 |
Dimitry Andric <dim@FreeBSD.org> |
Move all sources from the llvm project into contrib/llvm-project. This uses the new layout of the upstream repository, which was recently migrated to GitHub, and converted into a "monorepo". That is, most of the earlier separate sub-projects with their own branches and tags were consolidated into one top-level directory, and are now branched and tagged together. Updating the vendor area to match this layout is next. |
#
4014a71f |
|
23-Aug-2019 |
Dimitry Andric <dim@FreeBSD.org> |
Update build glue for a minimal build of the clang executable. |
#
36cb3905 |
|
21-Dec-2017 |
Dimitry Andric <dim@FreeBSD.org> |
First step in updating llvm/clang build glue: make only the clang executable build. |
#
5897d2f0 |
|
17-Apr-2017 |
Dimitry Andric <dim@FreeBSD.org> |
Initial update of clang/llvm build glue, for building just a minimal clang executable. |
#
986e05bc |
|
26-Aug-2016 |
Dimitry Andric <dim@FreeBSD.org> |
Completely revamp the way llvm, clang and lldb are built. * Bootstrap llvm-tblgen and clang-tblgen with a minimal llvm static library, that has no other dependencies. * Roll up all separate llvm libraries into one big static libllvm. * Similar for all separate clang and lldb static libraries. * For all these libraries, generate their .inc files only once. * Link all llvm tools (including extra) against the big libllvm. * Link clang and clang-format against the big libllvm and libclang. * Link lldb against the big libllvm, libclang and liblldb. N.B.: This is work in progress, some details may still be missing. It also heavily depends on bsd.*.mk's support for SRCS and DPSRCS with relative pathnames, which apparently does not always work as expected. For building llvm, clang and lldb though, it seems to work just fine. The main idea behind this restructuring is maintainability and build peformance. The previous large number of very small libraries, each with their own generated files and dependencies was slow to traverse and hard to understand. Possible future improvements: * Only build certain targets, e.g. for most regular users having just one target will be fine. This will shave off some build time. * Building the big llvm, clang and lldb libraries as shared (private) libraries. * Adding other components from the LLVM project, such as lld. |
#
5608fd23 |
|
19-Aug-2014 |
Bryan Drewery <bdrewery@FreeBSD.org> |
Revert r267233 for now. PIE support needs to be reworked. 1. 50+% of NO_PIE use is fixed by adding -fPIC to INTERNALLIB and other build-only utility libraries. 2. Another 40% is fixed by generating _pic.a variants of various libraries. 3. Some of the NO_PIE use is a bit absurd as it is disabling PIE (and ASLR) where it never would work anyhow, such as csu or loader. This suggests there may be better ways of adding support to the tree. Many of these cases can be fixed such that -fPIE will work but there is really no reason to have it in those cases. 4. Some of the uses are working around hacks done to some Makefiles that are really building libraries but have been using bsd.prog.mk because the code is cleaner. Had they been using bsd.lib.mk then NO_PIE would not have been needed. We likely do want to enable PIE by default (opt-out) for non-tree consumers (such as ports). For in-tree though we probably want to only enable PIE (opt-in) for common attack targets such as remote service daemons and setuid utilities. This is also a great performance compromise since ASLR is expected to reduce performance. As such it does not make sense to enable it in all utilities such as ls(1) that have little benefit to having it enabled. Reported by: kib |
#
864c53ea |
|
08-Jun-2014 |
Bryan Drewery <bdrewery@FreeBSD.org> |
In preparation for ASLR [1] support add WITH_PIE to support building with -fPIE. This is currently an opt-in build flag. Once ASLR support is ready and stable it should changed to opt-out and be enabled by default along with ASLR. Each application Makefile uses opt-out to ensure that ASLR will be enabled by default in new directories when the system is compiled with PIE/ASLR. [2] Mark known build failures as NO_PIE for now. The only known runtime failure was rtld. [1] http://www.bsdcan.org/2014/schedule/events/452.en.html Submitted by: Shawn Webb <lattera@gmail.com> Discussed between: des@ and Shawn Webb [2] |
#
3bdf7758 |
|
12-Apr-2014 |
Warner Losh <imp@FreeBSD.org> |
NO_MAN= has been deprecated in favor of MAN= for some time, go ahead and finish the job. ncurses is now the only Makefile in the tree that uses it since it wasn't a simple mechanical change, and will be addressed in a future commit. |
#
f785676f |
|
16-Feb-2014 |
Dimitry Andric <dim@FreeBSD.org> |
Upgrade our copy of llvm/clang to 3.4 release. This version supports all of the features in the current working draft of the upcoming C++ standard, provisionally named C++1y. The code generator's performance is greatly increased, and the loop auto-vectorizer is now enabled at -Os and -O2 in addition to -O3. The PowerPC backend has made several major improvements to code generation quality and compile time, and the X86, SPARC, ARM32, Aarch64 and SystemZ backends have all seen major feature work. Release notes for llvm and clang can be found here: <http://llvm.org/releases/3.4/docs/ReleaseNotes.html> <http://llvm.org/releases/3.4/tools/clang/docs/ReleaseNotes.html> MFC after: 1 month
|
#
139f7f9b |
|
12-Apr-2013 |
Dimitry Andric <dim@FreeBSD.org> |
Upgrade our copy of llvm/clang to trunk r178860, in preparation of the upcoming 3.3 release (branching and freezing expected in a few weeks). Preliminary release notes can be found at the usual location: <http://llvm.org/docs/ReleaseNotes.html> An MFC is planned once the actual 3.3 release is finished.
|
#
8a166caf |
|
11-Feb-2013 |
Andrew Turner <andrew@FreeBSD.org> |
Allow us to build clang for ARM EABI. Clang and llvm use the arm-gnueabi-freebsd10.0 triple for EABI. Use this when we are on arm or armv6 and are building for EABI. Reviewed by: dim |
#
3861d79f |
|
03-Dec-2012 |
Dimitry Andric <dim@FreeBSD.org> |
Upgrade our copy of llvm/clang to r168974, from upstream's release_32 branch. This is effectively llvm/clang 3.2 RC2; the 3.2 release is coming soon.
|
#
7ae0e2c9 |
|
20-Aug-2012 |
Dimitry Andric <dim@FreeBSD.org> |
Upgrade our copy of llvm/clang to trunk r162107. With thanks to Benjamin Kramer and Joerg Sonnenberger for their input and fixes.
|
#
6122f3e6 |
|
22-Oct-2011 |
Dimitry Andric <dim@FreeBSD.org> |
Upgrade our copy of llvm/clang to r142614, from upstream's release_30 branch. This brings us very close to the 3.0 release, which is expected in a week or two. MFC after: 1 week
|
#
48aaf27b |
|
06-Aug-2020 |
Dimitry Andric <dim@FreeBSD.org> |
Update Makefiles under lib/clang and usr.bin/clang for 11.0.0 builds, and also bump the version in the mtree files.
|
#
38b6f456 |
|
25-Jan-2020 |
Dimitry Andric <dim@FreeBSD.org> |
Adjust libllvmminimal and tblgen Makefiles so all the tblgen executables build.
|
#
0b57cec5 |
|
20-Dec-2019 |
Dimitry Andric <dim@FreeBSD.org> |
Move all sources from the llvm project into contrib/llvm-project. This uses the new layout of the upstream repository, which was recently migrated to GitHub, and converted into a "monorepo". That is, most of the earlier separate sub-projects with their own branches and tags were consolidated into one top-level directory, and are now branched and tagged together. Updating the vendor area to match this layout is next.
|
#
4014a71f |
|
23-Aug-2019 |
Dimitry Andric <dim@FreeBSD.org> |
Update build glue for a minimal build of the clang executable.
|
#
36cb3905 |
|
21-Dec-2017 |
Dimitry Andric <dim@FreeBSD.org> |
First step in updating llvm/clang build glue: make only the clang executable build.
|
#
5897d2f0 |
|
17-Apr-2017 |
Dimitry Andric <dim@FreeBSD.org> |
Initial update of clang/llvm build glue, for building just a minimal clang executable.
|
#
986e05bc |
|
26-Aug-2016 |
Dimitry Andric <dim@FreeBSD.org> |
Completely revamp the way llvm, clang and lldb are built. * Bootstrap llvm-tblgen and clang-tblgen with a minimal llvm static library, that has no other dependencies. * Roll up all separate llvm libraries into one big static libllvm. * Similar for all separate clang and lldb static libraries. * For all these libraries, generate their .inc files only once. * Link all llvm tools (including extra) against the big libllvm. * Link clang and clang-format against the big libllvm and libclang. * Link lldb against the big libllvm, libclang and liblldb. N.B.: This is work in progress, some details may still be missing. It also heavily depends on bsd.*.mk's support for SRCS and DPSRCS with relative pathnames, which apparently does not always work as expected. For building llvm, clang and lldb though, it seems to work just fine. The main idea behind this restructuring is maintainability and build peformance. The previous large number of very small libraries, each with their own generated files and dependencies was slow to traverse and hard to understand. Possible future improvements: * Only build certain targets, e.g. for most regular users having just one target will be fine. This will shave off some build time. * Building the big llvm, clang and lldb libraries as shared (private) libraries. * Adding other components from the LLVM project, such as lld.
|
#
5608fd23 |
|
19-Aug-2014 |
Bryan Drewery <bdrewery@FreeBSD.org> |
Revert r267233 for now. PIE support needs to be reworked. 1. 50+% of NO_PIE use is fixed by adding -fPIC to INTERNALLIB and other build-only utility libraries. 2. Another 40% is fixed by generating _pic.a variants of various libraries. 3. Some of the NO_PIE use is a bit absurd as it is disabling PIE (and ASLR) where it never would work anyhow, such as csu or loader. This suggests there may be better ways of adding support to the tree. Many of these cases can be fixed such that -fPIE will work but there is really no reason to have it in those cases. 4. Some of the uses are working around hacks done to some Makefiles that are really building libraries but have been using bsd.prog.mk because the code is cleaner. Had they been using bsd.lib.mk then NO_PIE would not have been needed. We likely do want to enable PIE by default (opt-out) for non-tree consumers (such as ports). For in-tree though we probably want to only enable PIE (opt-in) for common attack targets such as remote service daemons and setuid utilities. This is also a great performance compromise since ASLR is expected to reduce performance. As such it does not make sense to enable it in all utilities such as ls(1) that have little benefit to having it enabled. Reported by: kib
|
#
864c53ea |
|
08-Jun-2014 |
Bryan Drewery <bdrewery@FreeBSD.org> |
In preparation for ASLR [1] support add WITH_PIE to support building with -fPIE. This is currently an opt-in build flag. Once ASLR support is ready and stable it should changed to opt-out and be enabled by default along with ASLR. Each application Makefile uses opt-out to ensure that ASLR will be enabled by default in new directories when the system is compiled with PIE/ASLR. [2] Mark known build failures as NO_PIE for now. The only known runtime failure was rtld. [1] http://www.bsdcan.org/2014/schedule/events/452.en.html Submitted by: Shawn Webb <lattera@gmail.com> Discussed between: des@ and Shawn Webb [2]
|
#
3bdf7758 |
|
12-Apr-2014 |
Warner Losh <imp@FreeBSD.org> |
NO_MAN= has been deprecated in favor of MAN= for some time, go ahead and finish the job. ncurses is now the only Makefile in the tree that uses it since it wasn't a simple mechanical change, and will be addressed in a future commit.
|
#
8a166caf |
|
11-Feb-2013 |
Andrew Turner <andrew@FreeBSD.org> |
Allow us to build clang for ARM EABI. Clang and llvm use the arm-gnueabi-freebsd10.0 triple for EABI. Use this when we are on arm or armv6 and are building for EABI. Reviewed by: dim
|