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
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
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
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.
and sys/boot/pc98/boot2, do not simply assign 'gcc' to CC, since compile
flags are sometimes passed via this variable, for example during the
build32 stage on amd64. This caused the 32-bit libobjc build on amd64
to fail.
Instead, only replace the first instance of clang (if any, including
optional path) with gcc, and leave the arguments alone.
Approved-by: rpaulo (mentor)
Because FreeBSD no longer supports the 80386 cpu all code targeting
FreeBSD/i386 necessarily runs on i486 or higher so the compiler
built-ins can be used by default inside libstdc++ and in C++ headers.
This allows newly compiled C++ code to inline some atomic operations.
Old binaries continue to use libstdc++ functions.
PR: 148926
Tested by: Yuri Karaban <tech askold net>
Reviewed by: kan
Approved by: kib (mentor)
MFC after: 2 weeks
gnu/lib/libobjc and sys/boot/i386/boot2, so it also works when using
absolute paths and/or options, as in CC="/absolute/path/clang -foo".
Approved by: rpaulo (mentor)
selected() callback. When the dialog first appears, you will not see
the printed statement on the dialog, if you move down one, you will,
move up again and it now appears. I am assuming that you call a
*printw() function on a line in the dialog box of course.
The fix, from the pr:
This is a hack at best, I looked at the redraw code in
dialog_checklist() and took the minimal amount of it out to do
a simple "refresh" right after the items are drawn. This
doesn't hurt anything and makes the library work like it
should. There is probably a better way however =).
PR: 148609
Submitted by: John Hixson
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
error in /usr/lib/crtendS.o(.eh_frame); no .eh_frame_hdr table will be created.
The issue is that crtend is compiled with unwind table, and also it
places the special CIE into the .eh_frame indicating the end of section,
that is located before generated unwind table. New ld has assertion that
verifies that closing CIE is indeed the last CIE, causing the crypting
message to be issued, and refusing to generate dwarf unwind.
Add -fno-asynchronous-unwind-tables to disable unwind table generation
for crtbegin/crtend. While there, disable omitting the frame pointer [1].
Requested by: kan [1]
Reviewed by: kan
MFC after: 2 weeks
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
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.
both static and dynamic binaries compiled with or without stack
protection and should not depend on libssp_nonshared.a symbols.
Discussed with: kib
PR: bin/139052
preparation for 8.0-RELEASE. Add the previous version of those
libraries to ObsoleteFiles.inc and bump __FreeBSD_Version.
Reviewed by: kib
Approved by: re (rwatson)
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)
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)
getosreldate() in assembler source files. We still get the
definition of __FreeBSD_version this way, because it's
outside the standard multiple-inclusion protection trick.
All this is specific to ia64.
- It is opt-out for now so as to give it maximum testing, but it may be
turned opt-in for stable branches depending on the consensus. You
can turn it off with WITHOUT_SSP.
- WITHOUT_SSP was previously used to disable the build of GNU libssp.
It is harmless to steal the knob as SSP symbols have been provided
by libc for a long time, GNU libssp should not have been much used.
- SSP is disabled in a few corners such as system bootstrap programs
(sys/boot), process bootstrap code (rtld, csu) and SSP symbols themselves.
- It should be safe to use -fstack-protector-all to build world, however
libc will be automatically downgraded to -fstack-protector because it
breaks rtld otherwise.
- This option is unavailable on ia64.
Enable GCC stack protection (aka Propolice) for kernel:
- It is opt-out for now so as to give it maximum testing.
- Do not compile your kernel with -fstack-protector-all, it won't work.
Submitted by: Jeremie Le Hen <jeremie@le-hen.org>
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
libraries had not had their versions bumped relative to 6.3-REL but
had indeed been changed. We need to bump their version so they can be
properly added to the compat6x port:
libasn1.so.8 libgssapi.so.8 libhdb.so.8 libkadm5clnt.so.8
libkadm5srv.so.8 libkafs5.so.8 libkrb5.so.8 libobjc.so.2
MFC After: 1 day