360643 |
04-May-2020 |
dim |
Merge additions of LLVM libunwind libgcc_eh and libgcc_s. This is in preparation of further LLVM merges.
MFC r307230 (by emaste):
Introduce lib/libgcc_eh and lib/libgcc_s for LLVM's implementation
They are not yet connected to the build, but I am adding them to allow for easier testing, ports exp-runs, etc.
Reviewed by: ed Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D8188
MFC r307231 (by emaste):
libgcc_s: add libm dependencies from div{d,s,x}c3
compiler-rt's complex division support routines contain calls to compiler builtins such as `__builtin_scalbnl`. Unfortunately Clang turns these back into a call to `scalbnl`.
For now link libm's C version of the required support routines.
Reviewed by: ed Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D8190
MFC r307864 (by emaste):
Move the LLVM-based libgcc_s to /lib
When enabled, it should install in the same location as the existing library.
Reported by: antoine
MFC r308001 (by emaste):
libgcc_eh/libgcc_s: apply hidden visibility only to static libs
MFC r308100 (by emaste):
compile libunwind c source with -fexceptions
When an exception is thrown the unwinder must unwind its own C source (starting with _Unwind_RaiseException in UnwindLevel1.c), so it needs to be built with unwinding data.
MFC r308294 (by emaste):
libgcc_s: make unspecified shlib symbols local
We want only symbols explicitly specified in the Version.map.
Sponsored by: The FreeBSD Foundation
MFC r308308 (by emaste):
Connect new LLVM-based libgcc_eh & libgcc_s to the build
Compiler-rt and LLVM's libunwind provide a suitable replacement for libgcc.a, libgcc_eh.a, and libgcc_s.so.
Remove the now-unused LLVM_LIBUNWIND block from gnu/lib/libgcc.
PR: 213480 [exp-run] Reviewed by: brooks, ed Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D8189
MFC r308379 (by emaste):
add __divdi3 and __udivdi3 to libgcc_s symbol version map
After r308294 they were missing on i386 (and previously were exported only accidentally).
Reported by: antoine
MFC r308445 (by emaste):
add missing i386 symbols libgcc_s symbol version map
After r308294 they were missing on i386 (and previously were exported only accidentally).
Reported by: antoine
MFC r312076 (by emaste):
libgcc_s: add libc DT_NEEDED to fix underlinking
PR: 216012 Reported by: jbeich Sponsored by: The FreeBSD Foundation
MFC r316101 (by ngie):
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.
Reported by: Jenkins (FreeBSD-head-amd64-gcc) Tested with: amd64-gcc-6.3.0 (devel/amd64-xtoolchain-gcc) Sponsored by: Dell EMC Isilon
MFC r320673 (by emaste):
Sort entries in libgcc_s Version.map
MFC r337585 (by dim):
In r308100, an explicit -fexceptions flag was added for the C sources from LLVM's libunwind, which end up in libgcc_eh.a and libgcc_s.so. This is because the unwinder needs the unwinder data for its own functions.
However, for the C++ sources in libunwind, -fexceptions is already the default, and this can have the side effect of generating a reference to __gxx_personality_v0, the so-called personality function, which is normally provided by the C++ ABI library (libcxxrt or libsupc++).
If the reference ends up in the eventual libgcc_s.so, linking any non-C++ programs against it will fail with "undefined reference to `__gxx_personality_v0'".
Note that at high optimization levels, the reference is usually optimized away, which is why we have never noticed this problem before.
With clang 7.0.0 though, higher optimization levels don't help anymore, since the addition of address-significance tables [1] in <https://reviews.llvm.org/rL337339>. Effectively, this always causes a reference to __gxx_personality_v0.
After discussion with the upstream author of that change, it turns out that we should compile libunwind sources with the -fno-exceptions -funwind-tables flags instead. This ensures unwind tables are generated, but no references to any personality functions are emitted.
[1] https://lists.llvm.org/pipermail/llvm-dev/2018-May/123514.html
Reported by: jbeich PR: 230399 |
346296 |
16-Apr-2019 |
dim |
Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp 8.0.0 final release r356365.
MFC r306265 (by emaste):
Force LLVM_LIBUNWIND off if we don't have a C++11 compiler
Tested by: bde Differential Revision: https://reviews.freebsd.org/D7746
MFC r308100 (by emaste):
compile libunwind c source with -fexceptions
When an exception is thrown the unwinder must unwind its own C source (starting with _Unwind_RaiseException in UnwindLevel1.c), so it needs to be built with unwinding data.
MFC r324998 (by bdrewery):
Prefix {TARGET,BUILD}_TRIPLE with LLVM_ to avoid Makefile.inc1 collision.
The Makefile.inc1 TARGET_TRIPLE is for specifying which -target is used during the build of world.
Reviewed by: dim, imp Sponsored by: Dell EMC Isilon Differential Revision: https://reviews.freebsd.org/D12792
MFC r329093 (by emaste):
Promote llvm-cov to a standalone option
Introduce WITH_/WITHOUT_LLVM_COV to match GCC's WITH_/WITHOUT_GCOV. It is intended to provide a superset of the interface and functionality of gcov.
It is enabled by default when building Clang, similarly to gcov and GCC.
This change moves one file in libllvm to be compiled unconditionally. Previously it was included only when WITH_CLANG_EXTRAS was set, but the complexity of a new special case for (CLANG_EXTRAS | LLVM_COV) is not worth avoiding a tiny increase in build time.
Reviewed by: dim, imp Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D142645
MFC r331244 (by jhb):
Add support for MIPS to LLVM's libunwind.
This is originally based on a patch from David Chisnall for soft-float N64 but has since been updated to support O32, N32, and hard-float ABIs. The soft-float O32, N32, and N64 support has been committed upstream. The hard-float changes are still in review upstream.
Enable LLVM_LIBUNWIND on mips when building with a suitable (C+11-capable) toolchain. This has been tested with external GCC for all ABIs and O32 and N64 with clang.
Reviewed by: emaste Obtained from: CheriBSD (original N64 patch) Sponsored by: DARPA / AFRL Differential Revision: https://reviews.freebsd.org/D14701
MFC r336691 (by emaste):
llvm: remove __FreeBSD_version conditionals
All supported FreeBSD build host versions have backtrace.h, so we can just eliminate that test. For futimes() we can test the compiler's built-in __FreeBSD__ major version rather than relying on including osreldate.h. This should reduce the frequency with which Clang gets rebuilt when building world.
Reviewed by: dim Sponsored by: The FreeBSD Foundation
MFC r337379 (by andrew):
Default to armv5te in LINT on arm. This should fix building LINT there.
MFC r337552:
Add optional LLVM BPF target support
BPF (eBPF) is an independent instruction set architecture which is introduced in Linux a few years ago. Originally, eBPF execute environment was only inside Linux kernel. However, recent years there are some user space implementation (https://github.com/iovisor/ubpf, https://doc.dpdk.org/guides/prog_guide/bpf_lib.html) and kernel space implementation for FreeBSD is going on (https://github.com/YutaroHayakawa/generic-ebpf).
The BPF target support can be enabled using WITH_LLVM_TARGET_BPF, as it is not built by default.
Submitted by: Yutaro Hayakawa <yhayakawa3720@gmail.com> Reviewed by: dim, bdrewery Differential Revision: https://reviews.freebsd.org/D16033
MFC r337585:
In r308100, an explicit -fexceptions flag was added for the C sources from LLVM's libunwind, which end up in libgcc_eh.a and libgcc_s.so. This is because the unwinder needs the unwinder data for its own functions.
However, for the C++ sources in libunwind, -fexceptions is already the default, and this can have the side effect of generating a reference to __gxx_personality_v0, the so-called personality function, which is normally provided by the C++ ABI library (libcxxrt or libsupc++).
If the reference ends up in the eventual libgcc_s.so, linking any non-C++ programs against it will fail with "undefined reference to `__gxx_personality_v0'".
Note that at high optimization levels, the reference is usually optimized away, which is why we have never noticed this problem before.
With clang 7.0.0 though, higher optimization levels don't help anymore, since the addition of address-significance tables [1] in <https://reviews.llvm.org/rL337339>. Effectively, this always causes a reference to __gxx_personality_v0.
After discussion with the upstream author of that change, it turns out that we should compile libunwind sources with the -fno-exceptions -funwind-tables flags instead. This ensures unwind tables are generated, but no references to any personality functions are emitted.
[1] https://lists.llvm.org/pipermail/llvm-dev/2018-May/123514.html
Reported by: jbeich PR: 230399
MFC r340287 (by emaste):
Consolidate gcov entries in OptionalObsoleteFiles
Sponsored by: The FreeBSD Foundation
MFC r340289 (by emaste):
llvm-cov: also install as gcov (if GNU gcov is disabled)
llvm-cov provides a gcov-compatible interface when invoked as gcov.
Reviewed by: dim, markj Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D17923
MFC r340296 (by emaste):
Move llvm-profdata build into MK_LLVM_COV block
llvm-profdata is used with llvm-cov for code coverage (although llvm-cov can also operate independently in a gcov-compatible mode). Although llvm-profdata can be used independently of llvm-cov it makes sense to group these under one option.
Also handle these in OptionalObsoleteFiles.inc while here.
Sponsored by: The FreeBSD Foundation
MFC r340300 (by emaste):
libllvm: Move SampleProfWriter to SRCS_MIN
It is required by llvm-profdata, now built by default under the LLVM_COV knob. The additional complexity that would come from avoiding building it if CLANG_EXTRAS and LLVM_COV are both disabled is not worth the small savings in build time.
Sponsored by: The FreeBSD Foundation
MFC r340972 (by emaste):
llvm-objdump: initial man page
Based on llvm-objdump's online documentation and usage information. This serves as a starting point; additional detail and cleanup still required.
Also being submitted upstream in LLVM review D54864. I expect to use this bespoke copy while we have LLVM 6.0 or 7.0 in FreeBSD; when we update to LLVM 8.0 it should be upstream and we will switch to it.
PR: 233437 Reviewed by: bcr (man formatting) Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D18309
MFC r340973 (by emaste):
llvm-objdump.1: remove invalid options
Some options appear in llvm-objdump's usage information as a side effect of its option parsing implementation and are not actually llvm-objdump options. Reported in LLVM review https://reviews.llvm.org/D54864.
Reported by: Fangrui Song Sponsored by: The FreeBSD Foundation
MFC r340975 (by emaste):
llvm-objdump.1: fix igor / mandoc -Tlint warnings
Accidentally omitted from r340972.
MFC r341055 (by emaste):
llvm-objdump.1: remove more unintentional options
Some options come from static constructors in LLVM libraries and are automatically added to llvm's usage output. They're not really supposed to be llvm-objdump options.
Reported by: Fangrui Song in LLVM review D54864 Sponsored by: The FreeBSD Foundation
MFC r344779:
Upgrade our copies of clang, llvm, lld, lldb, compiler-rt and libc++ to the upstream release_80 branch r355313 (effectively, 8.0.0 rc3). The release will follow very soon, but no more functional changes are expected.
Release notes for llvm, clang and lld 8.0.0 will soon be available here: <https://releases.llvm.org/8.0.0/docs/ReleaseNotes.html> <https://releases.llvm.org/8.0.0/tools/clang/docs/ReleaseNotes.html> <https://releases.llvm.org/8.0.0/tools/lld/docs/ReleaseNotes.html>
PR: 236062 Relnotes: yes
MFC r344798 (by emaste):
libllvm: promote WithColor and xxhash to SRCS_MIN
The armv6 build failed in CI due to missing symbols (from these two source files) in the bootstrap Clang.
This affected only armv6 because other Clang-using archs are using LLD as the bootstrap linker, and thus include SRCS_MIW via LLD_BOOTSTRAP.
Reported by: CI, via lwhsu Sponsored by: The FreeBSD Foundation
MFC r344825:
Add a few missed files to the MK_LLVM_TARGET_BPF=yes case, otherwise clang and various other executables will fail to link with undefined symbols.
Reported by: O. Hartmann <ohartmann@walstatt.org>
MFC r344852:
Put in a temporary workaround for what is likely a gcc 6 bug (it does not occur with gcc 7 or later). This should prevent the following error from breaking the head-amd64-gcc CI builds:
In file included from /workspace/src/contrib/llvm/tools/lldb/source/API/SBMemoryRegionInfo.cpp:14:0: /workspace/src/contrib/llvm/tools/lldb/include/lldb/Target/MemoryRegionInfo.h:128:54: error: 'template<class _InputIterator> lldb_private::MemoryRegionInfos::MemoryRegionInfos(_InputIterator, _InputIterator, const allocator_type&)' inherited from 'std::__1::vector<lldb_private::MemoryRegionInfo>' using std::vector<lldb_private::MemoryRegionInfo>::vector; ^~~~~~ /workspace/src/contrib/llvm/tools/lldb/include/lldb/Target/MemoryRegionInfo.h:128:54: error: conflicts with version inherited from 'std::__1::vector<lldb_private::MemoryRegionInfo>'
Reported by: CI
MFC r344896:
Pull in r354937 from upstream clang trunk (by Jörg Sonnenberger):
Fix inline assembler constraint validation
The current constraint logic is both too lax and too strict. It fails for input outside the [INT_MIN..INT_MAX] range, but it also implicitly accepts 0 as value when it should not. Adjust logic to handle both correctly.
Differential Revision: https://reviews.llvm.org/D58649
Pull in r355491 from upstream clang trunk (by Hans Wennborg):
Inline asm constraints: allow ICE-like pointers for the "n" constraint (PR40890)
Apparently GCC allows this, and there's code relying on it (see bug).
The idea is to allow expression that would have been allowed if they were cast to int. So I based the code on how such a cast would be done (the CK_PointerToIntegral case in IntExprEvaluator::VisitCastExpr()).
Differential Revision: https://reviews.llvm.org/D58821
These should fix assertions and errors when using the inline assembly "n" constraint in certain ways.
In case of devel/valgrind, a pointer was used as the input for the constraint, which lead to "Assertion failed: (isInt() && "Invalid accessor"), function getInt".
In case of math/secp256k1, a very large integer value was used as input for the constraint, which lead to "error: value '4624529908474429119' out of range for constraint 'n'".
PR: 236216, 236194
MFC r344951:
Merge llvm, clang, compiler-rt, libc++, lld, and lldb release_80 branch r355677 (effectively, 8.0.0 rc4), resolve conflicts, and bump version numbers.
PR: 236062
MFC r345018:
Merge LLVM libunwind trunk r351319, from just before upstream's release_80 branch point. Afterwards, we will merge the rest of the changes in the actual release_80 branch.
PR: 236062
MFC r345019:
Merge LLVM libunwind release_80 branch r355677 (effectively, 8.0.0 rc4).
PR: 236062
MFC r345021:
Pull in r355854 from upstream llvm trunk (by Jonas Paulsson):
[RegAlloc] Avoid compile time regression with multiple copy hints.
As a fix for https://bugs.llvm.org/show_bug.cgi?id=40986 ("excessive compile time building opencollada"), this patch makes sure that no phys reg is hinted more than once from getRegAllocationHints().
This handles the case were many virtual registers are assigned to the same physreg. The previous compile time fix (r343686) in weightCalcHelper() only made sure that physical/virtual registers are passed no more than once to addRegAllocationHint().
Review: Dimitry Andric, Quentin Colombet https://reviews.llvm.org/D59201
This should fix a hang when compiling certain generated .cpp files in the graphics/opencollada port.
PR: 236313
MFC r345068 (by jhb):
Move libunwind out of contrib/llvm/projects.
Move LLVM's libunwind to its own contrib/ directory similar to other runtime libraries like libc++ and libcxxrt.
Reviewed by: dim, emaste Differential Revision: https://reviews.freebsd.org/D19534
MFC r345073:
Revert r308867 (which was originally committed in the clang390-import project branch):
Work around LLVM PR30879, which is about a bad interaction between X86 Call Frame Optimization on i386 and libunwind, by disallowing the optimization for i386-freebsd12.
This should fix some instances of broken exception handling when frame pointers are omitted, in particular some unittests run during the build of editors/libreoffice.
This hack will be removed as soon as upstream has implemented a more permanent fix for this problem.
And indeed, after r345018 and r345019, which updated LLVM libunwind to the most recent version, the above workaround is no longer needed. The upstream commit which fixed this is:
https://llvm.org/viewvc/llvm-project?view=revision&revision=292723
Specifically, 32 bit (i386-freebsd) executables optimized with omitted frame pointers and Call Frame Optimization should now behave correctly when a C++ exception is thrown, and the stack is unwound.
Upstream PR: https://llvm.org/bugs/show_bug.cgi?id=30879 PR: 236062
MFC r345152:
Merge llvm, clang, compiler-rt, libc++, libunwind, lld, and lldb release_80 branch r356034 (effectively, 8.0.0 rc5), resolve conflicts, and bump version numbers.
PR: 236062
MFC r345231:
Add LLVM openmp trunk r351319 (just before the release_80 branch point) to contrib/llvm. This is not yet connected to the build, the glue for that will come in a follow-up commit.
PR: 236062
MFC r345232:
Bootstrap svn:mergeinfo on contrib/openmp.
PR: 236062
MFC r345233:
Merge openmp release_80 branch r356034 (effectively, 8.0.0 rc5).
PR: 236062
MFC r345234:
Add openmp __kmp_gettid() wrapper, using pthread_getthreadid_np(3). This has also been submitted upstream.
PR: 236062
MFC r345283:
Enable building libomp.so for 32-bit x86. This is done by selectively enabling the functions that save and restore MXCSR, since access to this register requires SSE support.
Note that you may run into other issues with OpenMP on i386, since this *not* yet supported upstream, and certainly not extensively tested.
PR: 236062, 236582
MFC r345345:
Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp 8.0.0 final release r356365. There were no functional changes since the most recent merge, of 8.0.0 rc5.
Release notes for llvm, clang, lld and libc++ 8.0.0 are now available:
https://llvm.org/releases/8.0.0/docs/ReleaseNotes.html https://llvm.org/releases/8.0.0/tools/clang/docs/ReleaseNotes.html https://llvm.org/releases/8.0.0/tools/lld/docs/ReleaseNotes.html https://llvm.org/releases/8.0.0/projects/libcxx/docs/ReleaseNotes.html
PR: 236062
MFC r345349:
Pull in r352826 from upstream lld trunk (by Fangrui Song):
[ELF] Support --{,no-}allow-shlib-undefined
Summary: In ld.bfd/gold, --no-allow-shlib-undefined is the default when linking an executable. This patch implements a check to error on undefined symbols in a shared object, if all of its DT_NEEDED entries are seen.
Our approach resembles the one used in gold, achieves a good balance to be useful but not too smart (ld.bfd traces all DSOs and emulates the behavior of a dynamic linker to catch more cases).
The error is issued based on the symbol table, different from undefined reference errors issued for relocations. It is most effective when there are DSOs that were not linked with -z defs (e.g. when static sanitizers runtime is used).
gold has a comment that some system libraries on GNU/Linux may have spurious undefined references and thus system libraries should be excluded (https://sourceware.org/bugzilla/show_bug.cgi?id=6811). The story may have changed now but we make --allow-shlib-undefined the default for now. Its interaction with -shared can be discussed in the future.
Reviewers: ruiu, grimar, pcc, espindola
Reviewed By: ruiu
Subscribers: joerg, emaste, arichardson, llvm-commits
Differential Revision: https://reviews.llvm.org/D57385
Pull in r352943 from upstream lld trunk (by Fangrui Song):
[ELF] Default to --no-allow-shlib-undefined for executables
Summary: This follows the ld.bfd/gold behavior.
The error check is useful as it captures a common type of ld.so undefined symbol errors as link-time errors:
// a.cc => a.so (not linked with -z defs) void f(); // f is undefined void g() { f(); }
// b.cc => executable with a DT_NEEDED entry on a.so void g(); int main() { g(); }
// ld.so errors when g() is executed (lazy binding) or when the program is started (-z now) // symbol lookup error: ... undefined symbol: f
Reviewers: ruiu, grimar, pcc, espindola
Reviewed By: ruiu
Subscribers: llvm-commits, emaste, arichardson
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D57569
Together, these add support for --no-allow-shlib-undefined, and make it the default for executables, so they will fail to link if any symbols from needed shared libraries are undefined.
Reported by: jbeich PR: 236062, 236141
MFC r345449:
Pull in r356809 from upstream llvm trunk (by Eli Friedman):
[ARM] Don't form "ands" when it isn't scheduled correctly.
In r322972/r323136, the iteration here was changed to catch cases at the beginning of a basic block... but we accidentally deleted an important safety check. Restore that check to the way it was.
Fixes https://bugs.llvm.org/show_bug.cgi?id=41116
Differential Revision: https://reviews.llvm.org/D59680
This should fix "Assertion failed: (LiveCPSR && "CPSR liveness tracking is wrong!"), function UpdateCPSRUse" errors when building the devel/xwpe port for armv7.
PR: 236062, 236568 |
311178 |
03-Jan-2017 |
bdrewery |
MFC r305145:
DIRDEPS_BUILD: Avoid cyclic dependency with libc++. |
309843 |
11-Dec-2016 |
marcel |
MFC r305855, r306297, r306300, r306312-r306313
When MAKEOBJDIRPREFIX points to a case-insensitive file system, the build can break when different source files create the same object files (case-insensitivity speaking). This is the case for object files compiled with -fpic and shared libraries. The former uses an extension of ".So", and the latter an extension ".so". Rename shared object files from *.So to *.pico to match what NetBSD does.
Also: o Compile _Exit.c as C99_Exit.c, as it conflicts with _exit.s o Add entry to UPDATING o Document .pico extension |
308238 |
03-Nov-2016 |
gjb |
MFC r308148, r308150, r308156:
r308148: Fix packaging calendar(1) files.
r308150: Fix packaging /usr/share/examples/etc.
r308156: Fix packaging /usr/lib{,32}/libgcc_eh{,_p}.a.
Sponsored by: The FreeBSD Foundation |
303634 |
01-Aug-2016 |
emaste |
MFC r303396: rename ARM's libunwind.S to to avoid conflict with llvm libunwind
llvm libunwind includes a libunwind.cpp, but on ARM libunwind.S is found first in .PATH. Rename the latter one, since it is not going to be updated again.
Approved by: re (kib) |
303196 |
22-Jul-2016 |
emaste |
MFC libunwind improvements
r302450: libunwind: update to upstream snapshot r272680
The key improvement is that it may be built without cross-unwinding support, which significantly reduces the stack space requirement.
r302456: libunwind: enable only the native unwinder by default
This significantly reduces stack space requirements, and runtimes require only native unwinding.
r302475: libunwind: limit stack usage in unwind cursor
This may be reworked upstream but in the interim should address the stack usage issue reported in the PR.
r303016: llvm-libunwind: use conventional (non-Darwin) X86 register numbers
For historical reasons Darwin/i386 has ebp and esp swapped in the eh_frame register numbering. That is:
Darwin Other Reg # eh_frame eh_frame DWARF ===== ======== ======== ===== 4 ebp esp esp 5 esp ebp ebp
Although the UNW_X86_* constants are not supposed to be coupled to DWARF / eh_frame numbering they are currently conflated in LLVM libunwind, and thus we require the non-Darwin numbering.
PR: 206384 Approved by: re (kib) Sponsored by: The FreeBSD Foundation |
302408 |
08-Jul-2016 |
gjb |
Copy head@r302406 to stable/11 as part of the 11.0-RELEASE cycle. Prune svn:mergeinfo from the new branch, as nothing has been merged here.
Additional commits post-branch will follow.
Approved by: re (implicit) Sponsored by: The FreeBSD Foundation |
298218 |
18-Apr-2016 |
bdrewery |
Follow-up r297842: Rework header generation to fix always rebuilding.
This reworks the handling of common headers to just include the needed logic rather than invoke MAKE. This avoids the problem listed in r297842 and avoids other dependency tracking issues.
Pointyhat to: bdrewery Reported by: Nikolai Lifanov <lifanov@mail.lifanov.com> Sponsored by: EMC / Isilon Storage Division
|
298107 |
16-Apr-2016 |
gjb |
Merge the projects/release-pkg branch to head.
This allows packaging the base system with pkg(8), including but not limited to providing the ability to provide upstream binary update possibilities for non-tier-1 architectures.
This merge is a requirement of the 11.0-RELEASE, and as such, thank you to everyone that has tested the project branch.
Documentation in build(7) etc. is still somewhat sparse, but updates to those parts will follow.
Sponsored by: The FreeBSD Foundation
|
297842 |
12-Apr-2016 |
bdrewery |
META_MODE: Avoid changed build command every build.
Because the file is generated with -f using another Makefile, 2 different Makefiles are trying to handle the .meta file for the target. The obvious .NOMETA_CMP or .NOMETA on the ${MAKE} targets don't work as they are very limited in scope in bmake. Using .PHONY fixes the problem and ensures that the ${MAKE} command is always ran to check if it is outdated in the sub-make.
An example of the problem in gnu/lib/libgcc (with make -dM): /usr/obj/root/git/freebsd/gnu/lib/libgcc/tm.h.meta: 2: a build command has changed TARGET_CPU_DEFAULT="" HEADERS="options.h i386/biarch64.h i386/i386.h i386/unix.h i386/att.h dbxelf.h elfos-undef.h elfos.h freebsd-native.h freebsd-spec.h freebsd.h i386/x86-64.h i386/freebsd.h i386/freebsd64.h defaults.h" DEFINES="" /bin/sh /root/git/freebsd/gnu/lib/libgcc/../../../contrib/gcc/mkconfig.sh tm.h vs (cd /root/git/freebsd/gnu/lib/libgcc; make -f /root/git/freebsd/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile MFILE=/root/git/freebsd/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile GCCDIR=/root/git/freebsd/gnu/lib/libgcc/../../../contrib/gcc tm.h) Skipping meta for tm.h: .NOMETA (cd /root/git/freebsd/gnu/lib/libgcc; make -f /root/git/freebsd/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile MFILE=/root/git/freebsd/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile GCCDIR=/root/git/freebsd/gnu/lib/libgcc/../../../contrib/gcc tm.h) `tm.h' is up to date.
Sponsored by: EMC / Isilon Storage Division
|
296012 |
24-Feb-2016 |
bdrewery |
OBJS and POBJS have not been used since r215127.
r215127 disabled building of libgcc.a.
MFC after: 2 weeks Sponsored by: EMC / Isilon Storage Division
|
296002 |
24-Feb-2016 |
bdrewery |
Don't hide AR command as bsd.lib.mk's r283925 changed as well.
MFC after: 2 weeks Sponsored by: EMC / Isilon Storage Division
|
295989 |
24-Feb-2016 |
bdrewery |
DIRDEPS_BUILD: Regenerate without local dependencies.
These are no longer needed after the recent 'beforebuild: depend' changes and hooking DIRDEPS_BUILD into a subset of FAST_DEPEND which supports skipping 'make depend'.
Sponsored by: EMC / Isilon Storage Division
|
294935 |
27-Jan-2016 |
kan |
Make .debug file for libgcc_s.so.1 more useful.
The files compiled into libgcc_s.so.1 did not have -g on compiler command line, making generated .debug quite pointless.
|
294834 |
26-Jan-2016 |
br |
Make libgcc compilable on RISC-V.
|
294590 |
22-Jan-2016 |
emaste |
Restore libunwind.cpp to LLVM libunwind build (reverts r294576)
The unw_* functions are not exported, but are used internally.
|
294576 |
22-Jan-2016 |
emaste |
Drop HP libunwind (unw_*) functions from LLVM libunwind
They are not needed for exception handling.
|
294542 |
22-Jan-2016 |
emaste |
Remove old generated unwind.h when using LLVM libunwind
When not using LLVM libunwind, unwind.h is a generated header and a stale copy may remain in the OBJDIR after enabling LLVM libunwind. Explicitly remove it.
Reported by: bz Reviewed by: bdrewery Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D5019
|
294331 |
19-Jan-2016 |
emaste |
Remove local override for .cpp.o and .cpp.po rules
The local build rule used to set -fvisibility=hidden and -fPIC, in addition to -fexceptions and -D defines that had no effect.
With -fvisibility=hidden and -fPIC in STATIC_CXXFLAGS the standard bsd.lib.mk rules are suitable for libgcc_s's C++ source.
PR: 206381 Sponsored by: The FreeBSD Foundation
|
294308 |
19-Jan-2016 |
emaste |
Remove local override for .cpp.So rule
The standard bsd.lib.mk rule is suitable for libgcc_s's C++ source.
The local rule had the following non-functional argument differences or additions:
1. -DSHARED (rather than -DPIC from bsd.lib.mk)
The C++ sources don't have an #ifdef for either one.
2. -fexceptions
This is enabled by default for C++ so does not need to be set explicitly.
3. -D__GLIBC__=3
Not used by LLVM libunwind.
4. -DElfW=__ElfN
LLVM libunwind provides its own definition.
PR: 206381 Differential Revision: The FreeBSD Foundation
|
293450 |
09-Jan-2016 |
emaste |
Support use of LLVM's libunwind for exception unwinding
It is built in libgcc_s.so and libgcc_eh.a to simplify transition.
It is enabled by default on arm64 (where we previously had no other unwinder) and may be enabled for testing on other platforms by setting WITH_LLVM_LIBUNWIND in src.conf(5).
Also add compiler-rt's __gcc_personality_v0 implementation for use with the LLVM unwinder.
Relnotes: Yes Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D4787
|
291307 |
25-Nov-2015 |
bdrewery |
META MODE: Prefer INSTALL=tools/install.sh to lessen the need for xinstall.host.
This both avoids some dependencies on xinstall.host and allows bootstrapping on older releases to work due to lack of at least 'install -l' support.
Sponsored by: EMC / Isilon Storage Division
|
284481 |
16-Jun-2015 |
sjg |
new depends
|
284480 |
16-Jun-2015 |
sjg |
Hook extra libs to _LIBS so bsd.lib.mk can do its thing
Differential Revision: D2843 Reviewed by: imp
|
284421 |
15-Jun-2015 |
bapt |
Revert r284417 it is not necessary anymore
|
284417 |
15-Jun-2015 |
bapt |
Enforce overwritting SHLIBDIR
Since METAMODE has been added, sys.mk loads bsd.mkopt.mk which ends load loading bsd.own.mk which then defines SHLIBDIR before all the Makefile.inc everywhere.
This makes /lib being populated again.
Reported by: many
|
284345 |
13-Jun-2015 |
sjg |
Add META_MODE support.
Off by default, build behaves normally. WITH_META_MODE we get auto objdir creation, the ability to start build from anywhere in the tree.
Still need to add real targets under targets/ to build packages.
Differential Revision: D2796 Reviewed by: brooks imp
|
280993 |
02-Apr-2015 |
andrew |
Exclude the floating-point functions from libgcc_s on arm64, they are unneeded and will be provided by compiler-rt.
Sponsored by: The FreeBSD Foundation
|
275077 |
25-Nov-2014 |
bapt |
Convert to LIBADD Reduce overlinking
|
272350 |
01-Oct-2014 |
andrew |
Remove MK_ARM_EABI, the armeb issues have been fixed. The code to support the oabi is still in the tree, but it is expected this will be removed as developers work on surrounding code.
With this commit the ARM EABI is the only supported supported ABI by FreeBSD on ARMa 32-bit processors.
X-MFC after: never Relnotes: yes Differential Revision: https://reviews.freebsd.org/D876
|
270216 |
20-Aug-2014 |
ngie |
Add ${LIBC} to DPADD to fix "make checkdpadd"
Phabric: D632 Approved by: jmmv (mentor) MFC after: 2 weeks
|
268351 |
07-Jul-2014 |
marcel |
Remove ia64.
This includes: o All directories named *ia64* o All files named *ia64* o All ia64-specific code guarded by __ia64__ o All ia64-specific makefile logic o Mention of ia64 in comments and documentation
This excludes: o Everything under contrib/ o Everything under crypto/ o sys/xen/interface o sys/sys/elf_common.h
Discussed at: BSDcan
|
267845 |
24-Jun-2014 |
imp |
Make sure that the sub-makes for unwind.h start from the CURDIR (/usr/src) tree rather than the OBJDIR (/usr/obj) tree. This fixes broken incremental builds with the canonical MAKESYSPATH workaround of .../share/mk. This is a gross kludge.
|
265420 |
06-May-2014 |
imp |
Use src.opts.mk in preference to bsd.own.mk except where we need stuff from the latter.
|
264367 |
12-Apr-2014 |
des |
Introduce RANLIBFLAGS to mirror ARFLAGS and add -D to both. This sets all timestamps in static libraries to 0 so that consecutive builds from the same source, even on different machines, produce identical libraries.
MFC after: 3 weeks
|
260874 |
19-Jan-2014 |
marcel |
Revision 258428 changed gcc by virtue of having _bswapsi2 _bswapdi2 in libgcc, but this was not propagated to this file. Revision 260844 added them here for ia64 unbeknownst revision 258428. Fix it for all...
Pointed out by: pfg
|
260849 |
18-Jan-2014 |
ed |
Replace LIBGCC by LIBCOMPILER_RT.
We now use libcompiler_rt on all platforms now. Instead of referring directly to -lgcc and LIBGCC, use -lcompiler_rt and LIBCOMPILER_RT.
|
260844 |
18-Jan-2014 |
marcel |
For ia64, add _bswapsi2 & _bswapdi2. The audio/flac port uses the bswap32 builtin and the compiler emits a call to the libgcc function rather than generating inline code.
|
259730 |
22-Dec-2013 |
dim |
To avoid having to explicitly test COMPILER_TYPE for setting clang-specific or gcc-specific flags, introduce the following new variables for use in Makefiles:
CFLAGS.clang CFLAGS.gcc CXXFLAGS.clang CXXFLAGS.gcc
In bsd.sys.mk, these get appended to the regular CFLAGS or CXXFLAGS for the right compiler.
MFC after: 1 week
|
257733 |
06-Nov-2013 |
gjb |
Revert r257691, r257645: Let amd64/amd64 build again.
|
257691 |
05-Nov-2013 |
dim |
Fix libgcc build with gcc after r257645, by using -Wno-static-in-inline for clang only.
|
257645 |
04-Nov-2013 |
sbruno |
Quiesce warning around gcc_assert() for an inline macro that uses a static variable. This code has been moved around in gcc, but is still in use in the latest trunk version of the compiler.
gnu/lib/libgcc/../../../contrib/gcc/unwind-dw2.c:208:36: warning: static variable 'dwarf_reg_size_table' is used in an inline function with external linkage [-Wstatic-in-inline] gcc_assert (index < (int) sizeof(dwarf_reg_size_table));
|
249702 |
20-Apr-2013 |
ed |
Enable libcompiler-rt on MIPS.
Originally we disabled libcompiler-rt on MIPS and SPARC64, because of an issue where __clzdi2 and __ctzdi2 would cause endless recursion. This bug has been fixed in r230021 already, but for some reason we only switched to libcompiler-rt on SPARC64 -- not MIPS.
This means we can finally use <stdatomic.h> on all our architectures.
|
248401 |
17-Mar-2013 |
andrew |
Link libgcc_s against compiler-rt on ARM EABI. This allows us to use all of the symbols in compiler-rt, including the ones not available in the old libgcc. This fixes the build with clang which generates calls to funstions that are missing from libgcc_s.
|
245539 |
17-Jan-2013 |
andrew |
Add compiler support for the ARM EABI.
ARM EABI support is disabled by default and can be enabled by setting WITH_ARM_EABI when building, however only the kernel-toolchain target will work with this flag until the rest of the support is added.
|
244382 |
18-Dec-2012 |
andrew |
Get libcompiler-rt and libgcc building on ARM with clang.
* Don't provide clear_cache or the __sync_* functions on ARM with clang as they are provided by clang as builtin functions. * Tell clang it is aloud to compile some libgcc code using heinous GCC extensions.
|
243933 |
06-Dec-2012 |
eadler |
Clean up hardcoded ar(1) flags in the tree to use the global ARFLAGS in share/mk/sys.mk instead.
This is part of a medium term project to permit deterministic builds of FreeBSD.
Submitted by: Erik Cederstrand <erik@cederstrand.dk> Reviewed by: imp, toolchain@ Approved by: cperciva MFC after: 2 weeks
|
235487 |
15-May-2012 |
marius |
Switch sparc64 to using libcompiler_rt; since r230021 we have a workaround in place allowing it to be used there and since r235388 (see also r235486) we also have usable div/mod optimizations like libgcc has.
|
234546 |
21-Apr-2012 |
imp |
Replace a bare use of nm with ${NM} for easier cross compilation in environments where nm is spelled differently.
|
233644 |
29-Mar-2012 |
jmallett |
Assume a big-endian default on MIPS and drop the "eb" suffix from MACHINE_ARCH. This makes our naming scheme more closely match other systems and the expectations of much third-party software. MIPS builds which are little-endian should require and exhibit no changes. Big-endian TARGET_ARCHes must be changed: From: To: mipseb mips mipsn32eb mipsn32 mips64eb mips64
An entry has been added to UPDATING and some foot-shooting protection (complete with warnings which should become errors in the near future) to the top-level base system Makefile.
|
218181 |
02-Feb-2011 |
imp |
Revert last change now that the reason for it is no more... MACHINE_ARCH is now always mipsel when building mips/mips.
|
218064 |
29-Jan-2011 |
jchandra |
Rewrite the ARCH check another way for backward compatibility.
Compilation fails now, if TARGET_ARCH=mips instead of mipsel/mipseb.
|
217942 |
27-Jan-2011 |
jchandra |
Fix n32 compile.
These changes are needed to fix n32 compile after the recent change of mips n32 MACHINE_ARCH to mipsn32eb/mipsn32el.
Reviewed by: imp, bz (earlier version)
|
217123 |
07-Jan-2011 |
imp |
Retire TARGET_ABI.
Implement MACHINE_ARCH=mips64e[lb] to build N64 images. This replaces MACHINE_ARCH=mipse[lb] TARGET_ABI=n64.
MACHINE_ARCH=mipsn32e[lb] has been added, but currently requires WITHOUT_CDDL due to atomic issues in libzfs. I've not investigated this much, but implemented this to preserve as much of the TARGET_ABI functionality that I could. Since its presence doesn't affect the working cases, I've kept it in for now.
Added mips64e[lb] to make universe, so more kernels build.
And I think this (finally) closes the curtain on the tbemd tree.
|
216804 |
29-Dec-2010 |
kan |
Switch mips architectures back to libgcc.
MIPS64 n64 binaries are broken with libcompiler_rt at this time. Switch mips back to libgcc until the cause of breakage is analyzed and fixed.
|
215275 |
14-Nov-2010 |
imp |
These two cases should be different...
Submitted by: nathanw@
|
215185 |
12-Nov-2010 |
ed |
Revert to libgcc for sparc64.
I've had a report of a sparc64 system where cc1 generates illegal instructions. We still have to diagnose this properly, but instead of hosing all sparc64 boxes out there, fall back to libgcc to prevent more damage.
Reported by: Florian Smeets
|
215127 |
11-Nov-2010 |
ed |
Replace libgcc.a by libcompiler_rt.a.
libcompiler_rt.a is a BSD licensed C language runtime, which implements many routines which are linked into binaries on architectures where certain functionality is missing (e.g. 64 bits mul/div on i386).
Unfortunately, libcompiler_rt cannot replace libgcc entirely. Certain features, such as an unwinder for exception handling, are missing. That's why only libgcc.a is replaced for now, because this one does seem to be complete.
Tested by: rene (amd64), nwhitehorn (powerpc), droso (i386 exprun) and many others. Thanks! Obtained from: user/ed/compiler-rt
|
215126 |
11-Nov-2010 |
ed |
Don't use ${LIB} to obtain the library name.
Once we use libcompiler_rt, the LIB-line must go, to prevent libgcc.a from being built. Therefore, just hardcode the name.
Obtained from: user/ed/compiler-rt
|
215082 |
10-Nov-2010 |
imp |
Complete the integration of tbemd branch into head.
TARGET_BIG_ENDIAN is now completely dead, except where it was originally supposed to be used (internally in the toolchain building).
TARGET_ARCH has changed in three cases: (1) Little endian mips has changed to mipsel. (2) Big endian mips has changed to mipseb. (3) Big endian arm has changed to armeb.
Some additional changes are needed to make 'make universe' work on arm and mips after this change, so those are commented out for now.
UPDATING information will be forthcoming. Any remaining rough edges will be hammered out in -current.
|
209867 |
10-Jul-2010 |
nwhitehorn |
Teach our toolchain how to generate 64-bit PowerPC binaries. This fixes a variety of bugs in binutils related to handling of 64-bit PPC ELF, provides a GCC configuration for 64-bit PowerPC on FreeBSD, and associated build systems tweaks.
Obtained from: projects/ppc64
|
208737 |
02-Jun-2010 |
jmallett |
Add/improve mips64r2, Octeon, n32 and n64 support in the toolchain.
o) Add TARGET_ABI to the MIPS toolchain build process. This sets the default ABI to one of o32, n32 or n64. If it is not set, o32 is assumed as that is the current default. o) Set the default GCC cpu type to any specified TARGET_CPUTYPE. This is necessary to have a working "cc" if e.g. mips64 is specified, as binutils will refuse to link objects using different ISAs in some cases. o) Add support for n32 and n64 ABIs to binutils and GCC. o) Add additional required libgcc2 stubs for n32 and n64. o) Add support for the "mips64r2" architecture to GCC. Add the "octeon" o) When static linking, wrap default libraries in --start-group and --end-group. This is required for static linking to work on n64 with the interdependencies between libraries there. This is what other OSes that support n64 seem to do, as well. o) Fix our GCC spec to define __mips64 for 64-bit targets, not __mips64__, the former being what libgcc, etc., check and the latter seemingly being a misspelling of a hand merge from a Linux spec. o) When no TARGET_CPUTYPE is specified at build time, make GCC take the default ISA from the ABI. Our old defaults were too liberal and assumed that 64-bit ABIs should default to the MIPS64 ISA and that 32-bit ABIs should default to the MIPS32 ISA, when we are supporting or will support some systems based on earlier 32-bit and 64-bit ISAs, most notably MIPS-III. o) Merge a new opcode file (and support code) from a later version of binutils and add flags and code necessary to support Octeon-specific instructions. This should also make merging opcodes for other modern architectures easier.
Reviewed by: imp
|
207995 |
12-May-2010 |
obrien |
Non-GCC gcc compatible compilers may provide the same multimedia intrinsic headers as GCC, but of their own implementation. So put the GCC ones into their own header "namespace".
Requested by: ed
|
201852 |
08-Jan-2010 |
imp |
Merge r195030 from project/mips into head by hand:
r195030 | gonzo | 2009-06-25 19:27:31 -0600 (Thu, 25 Jun 2009) | 4 lines - Switch to libc softfloat from libgcc implementation. The problem with latter is that it is not complete, fpsetXXX/fpgetXXX functions are missing.
|
200499 |
14-Dec-2009 |
kan |
Fix one spelling and one copy&paste error in comments.
|
195697 |
14-Jul-2009 |
kan |
Second attempt at eliminating .text relocations in shared libraries compiled with stack protector.
Use libssp_nonshared library to pull __stack_chk_fail_local symbol into each library that needs it instead of pulling it from libc. GCC generates local calls to this function which result in absolute relocations put into position-independent code segment, making dynamic loader do extra work every time given shared library is being relocated and making affected text pages non-shareable.
Reviewed by: kib Approved by: re (kib)
|
195152 |
29-Jun-2009 |
kan |
Back out previous revision until better tested fix is ready.
Approved by: re (impliciti, by approving previos check-in)
|
195151 |
28-Jun-2009 |
kan |
Eliminate .text relocations in shared libraries compiled with stack protector.
Use libssp_nonshared library to pull __stack_chk_fail_local symbol into each library that needs it instead of pulling it from libc. GCC generates local calls to this function which result in absolute relocations put into position-independent code segment, making dynamic loader do extra work everys time given shared library is being relocated and making affected text pages non-shareable.
Reviewed by: kib Approved by: re (kensmith)
|
188583 |
13-Feb-2009 |
jkim |
Honor WITHOUT_INSTALLLIB in some places.
|
183167 |
19-Sep-2008 |
imp |
MFP4: Add mips to the list of soft-float platforms.
|
183165 |
19-Sep-2008 |
imp |
Prefer the patch in p4 to the patch in svn as it properly sorts the architectures alphabetically.
|
182627 |
01-Sep-2008 |
obrien |
Add FreeBSD/MIPS support to GCC.
|
176530 |
24-Feb-2008 |
raj |
Let PowerPC world optionally build with -msoft-float. For FPU-less PowerPC variations (e500 currently), this provides a gcc-level FPU emulation and is an alternative approach to the recently introduced kernel-level emulation (FPU_EMU).
Approved by: cognet (mentor) MFp4: e500
|
171846 |
14-Aug-2007 |
kan |
Remove comment that was added by mistakes and which prevented _eprintf and gcc_bcmp to be added to static libgcc.a.
Approved by: re (kensmith)
|
169718 |
19-May-2007 |
kan |
Update bmake glue to build GCC 4.2.
Also: Switch FreeBSD to use libgcc_s.so.1.
Use dl_iterate_phdr to locate shared objects' exception frame info instead of depending on older register_frame_info machinery. This allows us to avoid depending on libgcc_s.so.1 in binaries that do not use exception handling directly. As an additional benefit it breaks circular libc <=> libgcc_s.so.1 dependency too.
Build newly added libgomp.so.1 library, the runtime support bits for OpenMP.
Build LGPLed libssp library. Our libc provides our own BSD-licensed SSP callbacks implementation, so this library is only built to benefit applications that have hadcoded knowledge of libssp.so and libssp_nonshared.a. When linked in from command line, these libraries override libc implementation.
|
163279 |
12-Oct-2006 |
cognet |
Don't build the libgcc with functions already included in the libc to unbreak the build. We'll switch back to the libgcc functions and get rid of the libsoftfloat later.
|
156854 |
18-Mar-2006 |
ru |
Convert NO_PROFILE and NO_LIB32 to new style.
|
139106 |
21-Dec-2004 |
ru |
NODOCCOMPRESS -> NO_DOCCOMPRESS NOINFO -> NO_INFO NOINFOCOMPRESS -> NO_INFOCOMPRESS NOLINT -> NO_LINT NOPIC -> NO_PIC NOPROFILE -> NO_PROFILE
|
136910 |
24-Oct-2004 |
ru |
For variables that are only checked with defined(), don't provide any fake value.
|
133103 |
04-Aug-2004 |
kan |
Add missing patch which was forgotten during GCC 3.4.2 import. libgcc.a gets most of it content back now, when symbols from LIB2FUNCS are actually compiled.
Noticed by: Steve Kargl <gk at troutmask dot apl dot washington dot edu> Pointy hat to: kan
|
132751 |
28-Jul-2004 |
kan |
Bmake glue for GCC 3.4.2-prerelease.
|
117425 |
11-Jul-2003 |
kan |
Add unwind-c.c file required for -fexceptions in C sources.
|
117082 |
30-Jun-2003 |
ru |
Catch up with bsd.lib.mk,v 1.143.
|
116318 |
13-Jun-2003 |
peter |
Build/install the PIC version of libgcc (libcc_pic.a) for use by shared libraries that do exception unwinding.
|
104073 |
28-Sep-2002 |
peter |
Zap now-unused SHLIB_MINOR
|
103436 |
17-Sep-2002 |
peter |
Initiate deorbit burn for the i386-only a.out related support. Moves are under way to move the remnants of the a.out toolchain to ports. As the comment in src/Makefile said, this stuff is deprecated and one should not expect this to remain beyond 4.0-REL. It has already lasted WAY beyond that.
Notable exceptions: gcc - I have not touched the a.out generation stuff there. ldd/ldconfig - still have some code to interface with a.out rtld. old as/ld/etc - I have not removed these yet, pending their move to ports. some includes - necessary for ldd/ldconfig for now.
Tested on: i386 (extensively), alpha
|
96850 |
18-May-2002 |
obrien |
Fix the sparc64 build and make the LIB1ASMSRC handling more robust.
|
96846 |
18-May-2002 |
phk |
Improve chances that we correctly compile LIB1ASMSRC on all architectures.
sparc64 looked for the nonexistent sparc64/lb1spc.asm file instead of the sparc/lb1spc.asm file.
arm probably looked for arm/arm/lib1funcs.asm instead of arm/lib1funcs.asm ia64 probably looked for ia64/ia64/lib1funcs.asm instead of ia64/lib1funcs.asm
i386 and alpha don't seen to use the LIB1ASMSRC.
|
96799 |
17-May-2002 |
peter |
Move LIB1ASMFUNCS from the SYMS variable and explicitly add it to OBJS later. Otherwise make will try and build the supposedly assembler .o files from libgcc2.c - which does not work too well (the .o's have no content)
Reviewed by: obrien
|
96784 |
17-May-2002 |
obrien |
Post rev 1.39, the PowerPC specific additions to OBJS was getting lost.
|
96779 |
17-May-2002 |
obrien |
bsd.lib.mk now understands what to do with .asm files. So we can refer to these files by their real name vs. playing tricks renaming them during the build.
|
96456 |
12-May-2002 |
obrien |
Properly build lb1spc.asm on Sparc64.
|
96449 |
12-May-2002 |
obrien |
I was not strict enough with my ordering of things to satisfy make(1) nieve symbol evaluation which causes it to be very sensitive to macro ordering.
|
96343 |
10-May-2002 |
obrien |
[Ab]use LDFLAGS rather than CFLAGS. BDE tells me POSIX pretends `ld' as a directly callable entity does not exist.
|
96340 |
10-May-2002 |
obrien |
Bmake bits for Gcc 3.1.
Partially made possible by: Wilko.Bulte@compaq.com
|
95091 |
20-Apr-2002 |
obrien |
It is easier for me to debug with -I's at the rear.
|
93871 |
05-Apr-2002 |
obrien |
Style reorg. Also spell -fpic as determined by bsd.lib.mk.
|
70703 |
06-Jan-2001 |
obrien |
Use a unified libgcc rather than a seperate one for threaded and non-threaded programs. This provides threaded programs with the needed exception frame symbols.
parts submitted by: Max Khon <fjoe@iclub.nsu.ru> PR: 23252
|
61238 |
04-Jun-2000 |
obrien |
Scoot things over to the temporary *.295 source while I do major construction on the mainline sources.
|
58478 |
23-Mar-2000 |
obrien |
Clean up the FreeBSD configuration files -- includes removing the usage of svr4.h on the i386, and moving all the shared arch neutral bits into the FreeBSD general config header.
|
53263 |
17-Nov-1999 |
obrien |
Pay attention to the "KEEP THIS IN SYNC" comment, and sync the `tm.h' header with src/gcc/usr.bin/cc/cc_tools/Makefile.
|
53173 |
15-Nov-1999 |
obrien |
Cut over the system compiler from from EGCS 1.1.2 to GCC 2.95.2.
|
53162 |
15-Nov-1999 |
obrien |
Cosmetic change to match cc_tools/Makefile
|
51895 |
03-Oct-1999 |
bde |
Fixed the hack for using "../libgcc/Makefile" in libgcc_r/Makefile. ${LIB} was wrong at dependency-parsing time, so dependencies for libgcc_r*.a were wrong. This somehow worked right, except libgcc_r*.a were always out of date.
|
50472 |
27-Aug-1999 |
peter |
$Id$ -> $FreeBSD$
|
49865 |
16-Aug-1999 |
obrien |
Purely cosmetic changes -- fix Id's
|
45464 |
08-Apr-1999 |
obrien |
alpha/freebsd-elf.h has been merged with alpha/freebsd.h
|
45463 |
08-Apr-1999 |
obrien |
Don't require gcc/config/${MACHINE_ARCH}/xm-freebsd.h when we already know the contents of it. Instead create it, so all arch's are consistent.
|
45307 |
04-Apr-1999 |
obrien |
Conditionalize one more i386'ism.
|
45306 |
04-Apr-1999 |
obrien |
Attempt to creating the right ``tm.h'' file for the Alpha.
|
45299 |
04-Apr-1999 |
obrien |
Minimum set of changes to switch from Gcc 2.7.2 (in contrib/gcc) to Egcs 1.1.2 (in contrib/egcs)
|
45171 |
31-Mar-1999 |
obrien |
Add bits we were getting from gnu/usr.bin/cc/Makefile.inc.
|
42450 |
09-Jan-1999 |
jdp |
Switch to using ".So" as the extension for PIC object files rather than ".so". The old extension conflicted with well-established naming conventions for dynamically loadable modules.
The "clean" targets continue to remove ".so" files too, to deal with old systems.
|
39998 |
06-Oct-1998 |
peter |
Replace use of non-standard ld -O with a ld -o / mv combination as used elsewhere in the tree. Binutils doesn't support the -O hack^H^H^H^H extension. (actually, it ignores it for option compatability with some other OS).
|
37488 |
08-Jul-1998 |
bde |
Use a different hack for building libgcc2: `XCC= ${CC}' instead of `XCC= <relative cc> -B<path to relative cc1> ...'. This is equivalent when cc and cc1, etc. have just been bootstrapped by `make world'. The relative versions normally won't work if the target system is not binary compatible. Bootstrapping different versions of gcc without going through `make world' is slightly more broken than before.
Uniformized macro names (P1OBJS -> LIB1POBJS, etc.).
Don't give full paths to sources.
|
34814 |
23-Mar-1998 |
bde |
Support building of libgcc.a without building all of gcc. This is useful for bootstrapping. Compatible versions of gcc and cc1 should should be installed before using this feature.
|
22996 |
22-Feb-1997 |
peter |
Revert $FreeBSD$ to $Id$
|
21673 |
14-Jan-1997 |
jkh |
Make the long-awaited change from $Id$ to $FreeBSD$
This will make a number of things easier in the future, as well as (finally!) avoiding the Id-smashing problem which has plagued developers for so long.
Boy, I'm glad we're not using sup anymore. This update would have been insane otherwise.
|
18609 |
01-Oct-1996 |
peter |
Resync the libgcc functions list with the 2.7.2.1 tree. We were building a (now) defunct routine that no longer exists (causing an empty .o file), and were missing some others. Some of the ones we were missing are no-ops on the i386, so there are now 4 empty .o files.
(It seems that libc/quad has got some defunct functions now)
|
18441 |
21-Sep-1996 |
peter |
Remove the partial support for a shared -lcc_int, since it's been unusable for a fair while. cc1, cc1plus etc have been linked static for some time.
|
18390 |
19-Sep-1996 |
peter |
Man the lifeboats! Tie down the hatches! Red alert! Activate gcc-2.7.2.1!
(the old cc has been tagged with "gcc_2_6_3_final" so we have a reference point in case of unforseen disasters...)
This has the objc backend active, and I think I've managed to get the f77 f2c support through in one piece, but I don't know fortran to test it.
A 'make world' change and libobjc commit will follow.
If you normally do 'make -DNOCLEAN world', do not do so this time, I know it can fail with groff.
This version of gcc makes a **LOT** more warnings on our kernel.
|
15956 |
28-May-1996 |
phk |
Make rules reentrant.
|
15679 |
07-May-1996 |
wosch |
``mv'' -> ``mv -f'' ``rm'' -> ``rm -f'' so mv/rm may not ask for confirmation if you are not root
|
7040 |
12-Mar-1995 |
phk |
Don't install shared libgcc, we can't do it this way. I will uuencode and check in to a "compat20" area the 2.0-RELEASE version.
|
7019 |
12-Mar-1995 |
phk |
Remove a bunch of funtions that are in libc already. Add back the shared libgcc, now that we don't use it to link against.
|
6933 |
06-Mar-1995 |
jkh |
We can't bail out on generating the pic archive yet. Submitted by: bde
|
6930 |
06-Mar-1995 |
phk |
Don't make the shared libgcc. I don't belive we need the libgcc_pic.a anymore, so I killed that as well.
|
4491 |
15-Nov-1994 |
phk |
Integrated GCC-2.6.1 -> GCC-2.6.2 changes.
Notice that the libgcc DOESN'T change number, because there are no changes.
Also now the gnu2bmake stuff is synchronized again.
I commit this so that others can test too.
You might want to postpone any "make worlds" until tomorrow, to avoid any problems I didn't see in the first pass.
Thanks to Bruce for rounding up our changes to gcc.
|
4226 |
07-Nov-1994 |
phk |
As pointed out by Paul Traina, we need the libs to be 261.0 not 26.1.
|
4113 |
03-Nov-1994 |
phk |
---------------------------------- GCC-2.6.1 COMES TO FREEBSD-current ---------------------------------- Everybody needs to 'make world'.
Oakland, Nov 2nd 1994. In a surprise move this sunny afternoon, the release- engineer for the slightly delayed FreeBSD-2.0, Poul-Henning Kamp (28), decided to pull in the new version 2.6.1 of the GNU C-compiler. The new version of the compiler was release today at noon, and hardly 9 hours later it was committed into the FreeBSD-current source-repository. "It's is simply because we have had too much trouble with the version 2.6.0 of the compiler" Poul-Henning told the FreeBSD-Gazette, "we took a gamble when we decided to use that as our compiler for the 2.0 release, but it seems to pay of in the end now" he concludes. The move has not been discussed on the "core" list at all, and will come as a surprise for most Poul-Hennings peers. "I have only discussed it with Jordan [J. K. Hubbard, the FreeBSD's resident humourist], and we agreed that we needed to do it, so ... I did it!". After a breath he added with a grin: "My email will probably get an all time 'disk-full' now!". This will bring quite a flag-day to the FreeBSD developers, the patch-file is almost 1.4 Megabyte, and they will have to run "make world" to get entirely -current again. "Too bad, but we just had to do this." Was the only comment from Poul-Henning to these problems. When asked how this move would impact the 2.0 release-date, Poul-Hennings face grew dark, he mumbled some very Danish words while he moved his fingers in strange geometrical patterns. Immediately something ecclipsed the Sun, a minor tremor shook the buildings, and the temperature fell significantly. We decided not to pursure the question.
----------- JOB-SECTION ----------- Are you a dedicated GCC-hacker ? We BADLY need somebody to look at the 'freebsd' OS in gcc, sanitize it and carry the patches back to the GNU people. In particular, we need to get out of the "i386-only" spot we are in now. I have the stuff to take a gnu-dist into bmake-form, and will do that part.
Please apply to phk@freebsd.org
No Novice Need Apply.
|
1823 |
02-Aug-1994 |
phk |
Here comes the right import of gcc-2.6.0.
|