| #
3289bace
|
| 23-Nov-2025 |
Dimitry Andric <dim@FreeBSD.org> |
Reapply "Merge commit e24f90190c77 from llvm git (by Brad Smith):"
[Driver] Enable outline atomics for FreeBSD/aarch64 (#156089)
The compiler_rt helper functions have been built since 12.4, 13.
Reapply "Merge commit e24f90190c77 from llvm git (by Brad Smith):"
[Driver] Enable outline atomics for FreeBSD/aarch64 (#156089)
The compiler_rt helper functions have been built since 12.4, 13.1, 14 and anything newer.
This reverts commit bd27bd1f51d049538cc7a0053be9d99110a53ae1.
Only some people (including the release manager, unfortunately) ran into build issues with the previous iteration of this commit, because they were bootstrapping the compiler, either via the WITHOUT_SYSTEM_COMPILER src.conf(5) setting, or because the build system determined that their base system compiler was out of date.
The bootstrapped compiler would then enable outline atomics and compile libgcc_s with these, but because libgcc_s is linked with -nodefaultlibs, it could not find the helper routines in libcompiler_rt.a.
In contrast, people who did not bootstrap the compiler never saw any issues, because libgcc_s was built using their 'old' base system compiler, and so libgcc_s would not contain any calls to those helper routines.
Fix this by ensuring that libgcc_s is linked against libcompiler_rt.a explicitly, similar to some other binaries and libraries that are built with -nodefaultlibs.
Also, bump FREEBSD_CC_VERSION to ensure that everybody gets the updated compiler with outline atomics enabled. (This should have been done in the first iteration of this commit, because the error would have shown up right away then.)
MFC after: 3 days
show more ...
|
| #
e9ac4169
|
| 15-Jul-2024 |
Warner Losh <imp@FreeBSD.org> |
Remove residual blank line at start of Makefile
This is a residual of the $FreeBSD$ removal.
MFC After: 3 days (though I'll just run the command on the branches) Sponsored by: Netflix
|
| #
d0b2dbfa
|
| 16-Aug-2023 |
Warner Losh <imp@FreeBSD.org> |
Remove $FreeBSD$: one-line sh pattern
Remove /^\s*#[#!]?\s*\$FreeBSD\$.*$\n/
|
| #
1ab9996f
|
| 29-Mar-2023 |
John Baldwin <jhb@FreeBSD.org> |
libcompiler_rt/libgcc_s: Remove MIPS build glue.
Reviewed by: emaste Differential Revision: https://reviews.freebsd.org/D39328
|
| #
7bc797e3
|
| 02-Aug-2021 |
Alex Richardson <arichardson@FreeBSD.org> |
Add build system support for ASAN+UBSAN instrumentation
This adds two new options WITH_ASAN/WITH_UBSAN that can be set to enable instrumentation of all binaries with AddressSanitizer and/or Undefine
Add build system support for ASAN+UBSAN instrumentation
This adds two new options WITH_ASAN/WITH_UBSAN that can be set to enable instrumentation of all binaries with AddressSanitizer and/or UndefinedBehaviourSanitizer. This current patch is almost sufficient to get a complete buildworld with sanitizer instrumentation but in order to actually build and boot a system it depends on a few more follow-up commits.
Reviewed By: brooks, kib, markj Differential Revision: https://reviews.freebsd.org/D31043
show more ...
|
| #
7fa2f2a6
|
| 06-Jan-2021 |
Alex Richardson <Alexander.Richardson@cl.cam.ac.uk> |
Rename NO_WERROR -> MK_WERROR=no
As suggested in D27598. This also supports MK_WERROR.clang=no and MK_WERROR.gcc=no to support the existing NO_WERROR.<compiler> uses.
Reviewed By: brooks Differenti
Rename NO_WERROR -> MK_WERROR=no
As suggested in D27598. This also supports MK_WERROR.clang=no and MK_WERROR.gcc=no to support the existing NO_WERROR.<compiler> uses.
Reviewed By: brooks Differential Revision: https://reviews.freebsd.org/D27601
show more ...
|
| #
371f3da6
|
| 30-Apr-2020 |
John Baldwin <jhb@FreeBSD.org> |
Remove the SYMVER build option.
This option was added as a transition aide when symbol versioning was first added. It was enabled by default in 2007 and is supported even by the old GPLv2 binutils.
Remove the SYMVER build option.
This option was added as a transition aide when symbol versioning was first added. It was enabled by default in 2007 and is supported even by the old GPLv2 binutils. Trying to disable it currently fails to build in libc and at this point it isn't worth fixing the build.
Reported by: Michael Dexter Reviewed by: imp Differential Revision: https://reviews.freebsd.org/D24637
show more ...
|
| #
1fa29c42
|
| 16-Dec-2019 |
Michal Meloun <mmel@FreeBSD.org> |
Fix LLVM libunwnwind _Unwind_Backtrace symbol version for ARM. In original GNU libgcc, _Unwind_Backtrace is published with GCC_3.3 version for all architectures but ARM. For ARM should be publishes
Fix LLVM libunwnwind _Unwind_Backtrace symbol version for ARM. In original GNU libgcc, _Unwind_Backtrace is published with GCC_3.3 version for all architectures but ARM. For ARM should be publishes with GCC_4.3.0 version. This was originally omitted in r255095, fixed in r318024 and omitted aging in LLVM libunwind implementation in r354347.
For ARM _Unwind_Backtrace should be published as default with GCC_4.3.0 version , (because this is right original version) and again as normal(not-default) with GCC_3.3 version (to maintain ABI compatibility compiled/linked with wrong pre r318024 libgcc)
PR: 233664
show more ...
|
| #
c8b5e3de
|
| 05-Nov-2019 |
Conrad Meyer <cem@FreeBSD.org> |
Fix llvm-libunwind userspace build on ARM
GCC's libgcc exports a few ARM-specific symbols for ARM EABI, AEABI, or EHABI or whatever it's called. Export the same ones from LLVM-libunwind's libgcc_s,
Fix llvm-libunwind userspace build on ARM
GCC's libgcc exports a few ARM-specific symbols for ARM EABI, AEABI, or EHABI or whatever it's called. Export the same ones from LLVM-libunwind's libgcc_s, on ARM. As part of this, convert libgcc_s from a direct Version.map to one constructed from component Symbol.map files. This allows the ARM-specific Symbol.map to be included only on ARM.
Fix ARM-only oddities in struct name/aliases in LLVM-libunwind to match non-ARM definitions and ARM-specific expectations in libcxxrt / libcompiler_rt.
No functional change intended for non-ARM architectures.
This commit does not actually flip the switch for ARM defaults from libgcc to llvm-libunwind, but makes it possible (to compile, anyway).
show more ...
|
| #
3289bace
|
| 23-Nov-2025 |
Dimitry Andric <dim@FreeBSD.org> |
Reapply "Merge commit e24f90190c77 from llvm git (by Brad Smith):"
[Driver] Enable outline atomics for FreeBSD/aarch64 (#156089)
The compiler_rt helper functions have been built since 12.4, 13.
Reapply "Merge commit e24f90190c77 from llvm git (by Brad Smith):"
[Driver] Enable outline atomics for FreeBSD/aarch64 (#156089)
The compiler_rt helper functions have been built since 12.4, 13.1, 14 and anything newer.
This reverts commit bd27bd1f51d049538cc7a0053be9d99110a53ae1.
Only some people (including the release manager, unfortunately) ran into build issues with the previous iteration of this commit, because they were bootstrapping the compiler, either via the WITHOUT_SYSTEM_COMPILER src.conf(5) setting, or because the build system determined that their base system compiler was out of date.
The bootstrapped compiler would then enable outline atomics and compile libgcc_s with these, but because libgcc_s is linked with -nodefaultlibs, it could not find the helper routines in libcompiler_rt.a.
In contrast, people who did not bootstrap the compiler never saw any issues, because libgcc_s was built using their 'old' base system compiler, and so libgcc_s would not contain any calls to those helper routines.
Fix this by ensuring that libgcc_s is linked against libcompiler_rt.a explicitly, similar to some other binaries and libraries that are built with -nodefaultlibs.
Also, bump FREEBSD_CC_VERSION to ensure that everybody gets the updated compiler with outline atomics enabled. (This should have been done in the first iteration of this commit, because the error would have shown up right away then.)
MFC after: 3 days
show more ...
|
| #
e9ac4169
|
| 15-Jul-2024 |
Warner Losh <imp@FreeBSD.org> |
Remove residual blank line at start of Makefile
This is a residual of the $FreeBSD$ removal.
MFC After: 3 days (though I'll just run the command on the branches) Sponsored by: Netflix
|
| #
d0b2dbfa
|
| 16-Aug-2023 |
Warner Losh <imp@FreeBSD.org> |
Remove $FreeBSD$: one-line sh pattern
Remove /^\s*#[#!]?\s*\$FreeBSD\$.*$\n/
|
| #
1ab9996f
|
| 29-Mar-2023 |
John Baldwin <jhb@FreeBSD.org> |
libcompiler_rt/libgcc_s: Remove MIPS build glue.
Reviewed by: emaste Differential Revision: https://reviews.freebsd.org/D39328
|
| #
7bc797e3
|
| 02-Aug-2021 |
Alex Richardson <arichardson@FreeBSD.org> |
Add build system support for ASAN+UBSAN instrumentation
This adds two new options WITH_ASAN/WITH_UBSAN that can be set to enable instrumentation of all binaries with AddressSanitizer and/or Undefine
Add build system support for ASAN+UBSAN instrumentation
This adds two new options WITH_ASAN/WITH_UBSAN that can be set to enable instrumentation of all binaries with AddressSanitizer and/or UndefinedBehaviourSanitizer. This current patch is almost sufficient to get a complete buildworld with sanitizer instrumentation but in order to actually build and boot a system it depends on a few more follow-up commits.
Reviewed By: brooks, kib, markj Differential Revision: https://reviews.freebsd.org/D31043
show more ...
|
| #
7fa2f2a6
|
| 06-Jan-2021 |
Alex Richardson <Alexander.Richardson@cl.cam.ac.uk> |
Rename NO_WERROR -> MK_WERROR=no
As suggested in D27598. This also supports MK_WERROR.clang=no and MK_WERROR.gcc=no to support the existing NO_WERROR.<compiler> uses.
Reviewed By: brooks Differenti
Rename NO_WERROR -> MK_WERROR=no
As suggested in D27598. This also supports MK_WERROR.clang=no and MK_WERROR.gcc=no to support the existing NO_WERROR.<compiler> uses.
Reviewed By: brooks Differential Revision: https://reviews.freebsd.org/D27601
show more ...
|
| #
371f3da6
|
| 30-Apr-2020 |
John Baldwin <jhb@FreeBSD.org> |
Remove the SYMVER build option.
This option was added as a transition aide when symbol versioning was first added. It was enabled by default in 2007 and is supported even by the old GPLv2 binutils.
Remove the SYMVER build option.
This option was added as a transition aide when symbol versioning was first added. It was enabled by default in 2007 and is supported even by the old GPLv2 binutils. Trying to disable it currently fails to build in libc and at this point it isn't worth fixing the build.
Reported by: Michael Dexter Reviewed by: imp Differential Revision: https://reviews.freebsd.org/D24637
show more ...
|
| #
1fa29c42
|
| 16-Dec-2019 |
Michal Meloun <mmel@FreeBSD.org> |
Fix LLVM libunwnwind _Unwind_Backtrace symbol version for ARM. In original GNU libgcc, _Unwind_Backtrace is published with GCC_3.3 version for all architectures but ARM. For ARM should be publishes
Fix LLVM libunwnwind _Unwind_Backtrace symbol version for ARM. In original GNU libgcc, _Unwind_Backtrace is published with GCC_3.3 version for all architectures but ARM. For ARM should be publishes with GCC_4.3.0 version. This was originally omitted in r255095, fixed in r318024 and omitted aging in LLVM libunwind implementation in r354347.
For ARM _Unwind_Backtrace should be published as default with GCC_4.3.0 version , (because this is right original version) and again as normal(not-default) with GCC_3.3 version (to maintain ABI compatibility compiled/linked with wrong pre r318024 libgcc)
PR: 233664
show more ...
|
| #
c8b5e3de
|
| 05-Nov-2019 |
Conrad Meyer <cem@FreeBSD.org> |
Fix llvm-libunwind userspace build on ARM
GCC's libgcc exports a few ARM-specific symbols for ARM EABI, AEABI, or EHABI or whatever it's called. Export the same ones from LLVM-libunwind's libgcc_s,
Fix llvm-libunwind userspace build on ARM
GCC's libgcc exports a few ARM-specific symbols for ARM EABI, AEABI, or EHABI or whatever it's called. Export the same ones from LLVM-libunwind's libgcc_s, on ARM. As part of this, convert libgcc_s from a direct Version.map to one constructed from component Symbol.map files. This allows the ARM-specific Symbol.map to be included only on ARM.
Fix ARM-only oddities in struct name/aliases in LLVM-libunwind to match non-ARM definitions and ARM-specific expectations in libcxxrt / libcompiler_rt.
No functional change intended for non-ARM architectures.
This commit does not actually flip the switch for ARM defaults from libgcc to llvm-libunwind, but makes it possible (to compile, anyway).
show more ...
|
| #
9de4d0b1
|
| 31-Jan-2018 |
Glen Barber <gjb@FreeBSD.org> |
Fix build by escaping a line break.
PR: 225597 Submitted by: cbnfinley at gmail.com Sponsored by: The FreeBSD Foundation
|
| #
2c4bb7e3
|
| 31-Jan-2018 |
John Baldwin <jhb@FreeBSD.org> |
Don't include long double routines on architectures with small long double.
Reviewed by: emaste Sponsored by: DARPA / AFRL Differential Revision: https://reviews.freebsd.org/D13874
|
| #
b0a39ef0
|
| 28-Mar-2017 |
Enji Cooper <ngie@FreeBSD.org> |
Apply r315689 to lib/libgcc_s as well to unbreak the gcc xtoolchain build
lib/libgcc_s consumes lib/libcompiler_rt/Makefile*. The NO_WERROR.gcc in lib/libcompiler_rt/Makefile doesn't seem to have ma
Apply r315689 to lib/libgcc_s as well to unbreak the gcc xtoolchain build
lib/libgcc_s consumes lib/libcompiler_rt/Makefile*. The NO_WERROR.gcc in lib/libcompiler_rt/Makefile doesn't seem to have made a difference in being able to build this, so sprinkle NO_WERROR.gcc here as well.
MFC after: 3 days Reported by: Jenkins (FreeBSD-head-amd64-gcc) Tested with: amd64-gcc-6.3.0 (devel/amd64-xtoolchain-gcc) Sponsored by: Dell EMC Isilon
show more ...
|
| #
d370fd1c
|
| 14-Jan-2017 |
Dimitry Andric <dim@FreeBSD.org> |
Merge ^/head r311940 through r312200.
|
| #
2f21ec01
|
| 13-Jan-2017 |
Ed Maste <emaste@FreeBSD.org> |
libgcc_s: add libc DT_NEEDED to fix underlinking
PR: 216012 Reported by: jbeich MFC after: 1 week Sponsored by: The FreeBSD Foundation
|
| #
67bc8c8b
|
| 19-Nov-2016 |
Dimitry Andric <dim@FreeBSD.org> |
Merge ^/head r308491 through r308841.
|
| #
2ed1e385
|
| 11-Nov-2016 |
Ed Maste <emaste@FreeBSD.org> |
libcc_{s,eh}: build without SSP
As in the gnu/lib/libgcc Makefile: libgcc is linked in last and thus cannot depend on ssp symbols coming from earlier libraries. Disable stack protection
libcc_{s,eh}: build without SSP
As in the gnu/lib/libgcc Makefile: libgcc is linked in last and thus cannot depend on ssp symbols coming from earlier libraries. Disable stack protection for this library.
Reviewed by: dim Sponsored by: The FreeBSD Foundation
show more ...
|