not page aligned. To do this, use the ld script gnu ld installs on my
system.
This is imperfect: LDFLAGS_BIN and LD_FLAGS_BIN describe different
things. The loader script could be better named and take into account
other architectures. And having two different mechanisms to do
basically the same thing needs study. However, it's blocking forward
progress on lld, so I'll work in parallel to sort these out.
Differential Revision: https://reviews.freebsd.org/D7409
Reviewed by: emaste
hate adding yet another define, but it is the lessor of the evil
choices available. Kill another evil by removing PATH_BOOT3 and
replacing it with PATH_LOADER or PATH_LOADER_ZFS as appropriate.
PR: 206659
magic number to use V86_CY() instead. These should have been fixed as
part of the cleanup in r226746 but were missed.
The md5 sums of the object files were unchanged, so there should be no
functional change.
PR: 205424
Submitted by: Alexander Kuleshov <kuleshovmail@gmail.com>
MFC after: 1 week
stage, just like for the regular world stage.
Reviewed by: rodrigc, imp, bapt, emaste
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D2187
-mno-align-long-strings when compiling with base gcc. This is checked
by comparing the version number against 4.2.1, which is not exactly
right, but good enough. (There is no other way to check whether we are
using the non-standard gcc in base, as far as I know.)
Reported by: rodrigc
MFC after: 3 days
When building some of the boot loaders with clang, and DEBUG_FLAGS or
CFLAGS having '-g' in it, clang outputs several assembly directives that
are too new for our version of binutils.
Therefore, assemble the resulting .s files with clang instead. A more
general solution can be implemented when a GNU as-compatible driver for
clang's integrated assembler appears.
Tested by: gjb
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
percentage of machines has a 16550. Disable it for pc98 since only a
tiny fraction of them have one. These changes save 293 bytes when
building with clang, but preserves the ability to build with serial if
you really want. We now have 92 bytes free (412 with the in-tree gcc).
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]
directly to the linker (LD_FLAGS) from flags passed indirectly, via the
compiler driver (LDFLAGS).
This is because several Makefiles under sys/boot/i386 and sys/boot/pc98
use ${LD} directly to link, and the normal LDFLAGS value should not be
used in these cases.
MFC after: 3 days
being defined in <sys/diskmbr.h>. Instead give the symbols here a
"PC98_" prefix. This way, both <sys/diskmbr.h> and <sys/diskpc98.h>
can be included in the same C source file.
The renaming is trivial. The only gotcha is that DOSBBSECTOR is
also redefined from 0 to 1. This because DOSBBSECTOR was always
used in conjunction with an addition of 1. The PC98_BBSECTOR symbol
is defined as 1 and the expression is simplified.
Note: it is not believed that ports are seriously impacted; or at
all for that matter.
Approved by: nyan@
default compiler. This has two parts:
- Make sys/boot/pc98/boot2 always build with gcc for now, until we can
figure out a way to shrink it enough when building with clang.
- Since sys/boot/p98/cdboot uses .code16 directives, which are not yet
supported by clang's integrated assembler, use -no-integrated-as,
similar to sys/boot/i386/cdboot.
Reviewed by: nyan
MFC after: 1 week
- Mark getc() as inline, this has no effect on gcc but helps clang.
- Move getc() body before xgetc() so gcc does not emit a warning about
function having no body.
This patch shrinks boot2 a little.
o It switches kname to be just a pointer instead of an array.
o It changes ioctl to unsigned from uint8_t.
o It changes the second keyhit limit to 3 seconds from 5.
o It removes bi_basemem/bi_extmem/bi_memsizes_valid setting.
In sys/boot/i386/boot2/boot2.c, change the type of the 'opts' variable
from uint16_t back to uint32_t. The actual option bitmasks (RB_* and
RBX_*) assume at least a 32 bit variable.
Submitted by: rdivacky
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)
which also avoids NULL pointer arithmetic, as suggested by jhb. The
available space goes from 11 bytes to 7.
Reviewed by: nyan
Approved by: rpaulo (mentor)
It's based on the newest i386's one and has the advantage of:
- ELF binary support.
- UFS2 filesystem support.
- Many FreeBSD slices support on a disk.
Tested by: SATOU Tomokazu ( tomo1770 _ maple _ ocn _ ne _ jp ),
WATANABE Kazuhiro ( CQG00620 _ nifty _ ne _ jp ) and
nyan
MFC after: 2 week
Happy New Year in Japan!!
