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)
In particular, vendor sources that aren't ready for gnu99 should
still be compiled with gnu89. (Before r189824, these would have
generated warnings if you tried to compile them in gnu99 mode,
but the warnings went unheeded due to -Wno-error.)
This change was erronously ommitted from the r185690, and attempt
to simply add the prototype to string.h has revealed that several
contributed programs defined local prototypes for strndup(), controlled
by autoconfed config.h. So, manually change #undef HAVE_STRNDUP to
#define HAVE_STRNDUP 1. Next import of the corresponding program would
regenerate config.h, overriding the changes in this commit.
No objections from: kan
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.
control over the result of buildworld and installworld; this especially
helps packaging systems such as nanobsd
Reviewed by: various (posted to arch)
MFC after: 1 month
ABI change on ILP32 platforms and relating to events. However
it's harmless on little-endian ILP32 platforms in the sense
that it doesn't cause breakages. Old ILP32 thread libraries
write a 32-bit th_p and new thread libraries write a 64-bit
th_p. But due to the fact that we have an unused 32-bit data
field right after th_p and that field is always initialized to
zero, little-endian ILP32 machines effectively have a valid
64-bit th_p by accident. Likewise for new thread libraries and
old libthread_db: little endian ILP32 is unaffected.
At this time we don't support big-endian threaded applications
in GDB, so the breakage for the ILP32 case goes unnoticed.
is based on an old implementation from the University of Michigan with lots of
changes and fixes by me and the addition of a Solaris-compatible API.
Sponsored by: Isilon Systems
Reviewed by: alfred
conflicts due to radically different approaches to security and bug fixes.
In some cases I re-started from the vendor version and reimplemented our
patches. Fortunately, this is not enabled by default in -current.
- 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>
