Age | Commit message (Collapse) | Author |
|
Follows a similar model as NetBSD. Much help from patrick, kettenis and guenther.
lldb and lldb-server remain not installed by default.
ok patrick@
|
|
ok partrick@, kettenis@
|
|
For this architecture we use separate retguard prologue and epilogue code
for static or PIC code. In the PIC case we use some additional code before
the retguard epilogue to recover the function start address and the GOT
pointer in order to get the per-function random cookie. Much thanks to
visa@ for suggestions and advice making it all work.
ok deraadt@ visa@
|
|
okay guenther@ kettenis@
|
|
|
|
ok visa@
|
|
From Edgar Pettijohn <edgar () pettijohn-web ! com>
|
|
Reminded by brynet@
|
|
frame pointer for better use and lets the compiler run a little faster.
The resulting compiler binary is a half bit smaller too.
Note that frame pointer elimination is not applicable everywhere.
mips64 has the tooling that allow its use in this case.
OK kettenis@
|
|
|
|
OK brynet@, bluhm@
|
|
This patch sets the section in perl manpages to "3p" instead of "3"
which should be less confusing as you do find them in section 3p
on OpenBSD.
Initial idea and OK espie@, makes sense to schwarze@
|
|
|
|
which tried to figure out whether mandoc supported UTF-8 output
(which it has been doing since 2011) and which passed the -T locale
option (which has been the default since 2014 and always will)
but which required the -V option to work (which was deleted half
a decade ago and will not come back).
Nowadays, it is safe to assume that mandoc just works with UTF-8
on both the input and output sides - in literally each and every
operating system providing a mandoc port or package, even those
that are seriously lagging behind.
This patch will also be pushed upstream.
OK tb@
|
|
|
|
|
|
|
|
Minor bugfixes and documentation improvments. See perldelta for details.
https://metacpan.org/pod/release/SHAY/perl-5.28.2/pod/perldelta.pod
OK bluhm@
|
|
|
|
no functional change intended;
OK patrick@
|
|
no functional change intended;
OK millert@
|
|
It was only used in a very unsystematic way for a small minority
of Perl manual pages anyway, and using it consistently would entail
unsustainable maintenance workload.
Using input from afresh1@ espie@ and Grinnz#p5p;
OK afresh1@ espie@ jmc@.
|
|
Patch clang.rst such that "gmake -f Makefile.sphinx man" keeps working.
Using input from jsg@; OK patrick@; "no worries" deraadt@
|
|
variable and fall back to what stty(1) reports, and it does so with
nroff(1), but it didn't with mandoc(1) because it didn't know how
to pass the desired width to mandoc. Teach it to use "-O width=".
OK afresh1@.
I noticed the unimplemented feature when Andrew Daugherity asked
on tech@ what the point of a certain patch in FreeBSD is (which it
turns out we don't need).
|
|
output in UTF-8 encoding on OpenBSD. The consumer is always mandoc(1)
on OpenBSD, which can always handle UTF-8 input (no matter what LC_CTYPE
is) and which always produces useful output: UTF-8 for LC_CTYPE=*.UTF-8
or ASCII otherwise, in particular for LC_CTYPE=C.
Patch written after afresh1@ reported that "perldoc -oman" output
looked bad in both output modes.
OK afresh1@.
|
|
From Andrew Daugherity <andrew.daugherity () gmail ! com>
Corrections to fix and OK millert@, suggestions and OK schwarze@
|
|
maximum reachability of the PowerPC branch instructions.
Also override NOPIE_FLAGS to avoid building code with -fno-pie as doing so
is incompatible with secure-plt when using clang as the compiler.
ok visa@, guenther@
|
|
OK deraadt@ millert@ kettenis@
|
|
from unsigned long to int.
OK deraadt@ millert@ kettenis@
|
|
I don't know much about compilers, but what I do have are a very particular
set of skills. Skills I have acquired over a very long career.
|
|
static-linked against private copy, or dynamic tools against the *.so,
or ports use independent componented versions. Saves ~85MB in /usr.
ok jsg
|
|
ld --start-group --end-group block. bfd ld seems to need this where
lld doesn't.
|
|
build so external users of Support/TargetSelect.h will work correctly.
Previously these were defined via -D in CPPFLAGS.
Fixes llvmpipe erroring out due to no targets being registered.
ok patrick@
|
|
making sure LLVM_ARCH is set before including architecture-specific
Makefiles.
ok deraadt@
|
|
Generated with gmake and py-sphinx installed via
cd /usr/src/gnu/llvm/docs && gmake -f Makefile.sphinx man
|
|
This is required to build the radeonsi Mesa driver.
ok patrick@
|
|
|
|
A build time dependency on python is avoided by generating the arch
specific list of library components in advance. A 'reconf' target
is included to regenerate them. Approach discussed with patrick@
|
|
ld(1) would try to free uninitialized memory when used with -r -b binary
<fontfile> by ports/textproc/mupdf. Perform the same bfd type check
as bfd_elf_match_symbols_in_sections(). Fix found the hard way,
cheese and wine sponsor: miod. Almost identical fix already present
upstream.
Also set the freed pointer to NULL, just in case.
ok tb@ sthen@
|
|
libLLVM from a single directory avoid reused filenames by symlinking
duplicated names with a prefix of the component library name so object
file names will be unique.
symlink approach suggested by deraadt@ ok patrick@
|
|
matches the result of building with cmake
ok patrick@
|
|
ok patrick@
|
|
As of usr.bin/xinstall/install.c revision 1.68, -S is a no-op and
install(1) will always create files safely, thus clean the option usage
from the tree.
Diff from Lauri Tirkkonen <lotheac at iki dot fi>, thanks.
|
|
causes problems in the following files which use PIC as a variable name.
Undefine PIC in llvm-config.h to minimise the diff to upstream LLVM.
include/llvm/MC/MCObjectFileInfo.h
lib/MC/MCObjectFileInfo.cpp
lib/Transforms/Scalar/LICM.cpp
lib/Transforms/Utils/PredicateInfo.cpp
These are the files that would be built as part of a shared libLLVM.
There are other files with PIC variable names in clang code.
#undef PIC approach suggested by kettenis@
|
|
looking good sthen@, Great! bluhm@
|
|
looking good sthen@, Great! bluhm@
|
|
looking good sthen@, Great! bluhm@
|
|
looking good sthen@, Great! bluhm@
|
|
|
|
|