'wchar_t' is 7 characters long, not 6. r303297 fixed this in libelftc,
but not the second copy of this file that we have in libcxxrt.
PR: 208661
Submitted by: Daniel McRobb
Obtained from: ELF Tool Chain r3480
MFC after: 3 days
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.
Reviewed by: andrew
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D7162
which is more efficient.
Note that for now we do not create a separate library for libdivsufsort
because it's not used anywhere else.
Obtained from: Chromium
MFC after: 2 months
The addition of the referenceCount to __cxa_allocate_exception put the
unwindHeader at offset 0x58 in __cxa_exception, but it requires 16-byte
alignment. In order to avoid changing the current __cxa_exception ABI
(and thus breaking its consumers), add explicit padding in the
allocation routines (and account for it when freeing).
This is intended as a lower-risk change for FreeBSD 11. A "more correct"
fix should be prepared for upstream and -CURRENT.
Reviewed by: dim
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D7271
_Unwind_Exception is required to be double word aligned. GCC has
interpreted this to mean "use the maximum useful alignment for the
target" so follow that lead.
Obtained from: LLVM review D22543
FreeBSD uses LLVM's libunwind on FreeBSD/arm64 today (and we expect to
use it more widely in the future) and it requires the EH frame segment
in static binaries.
Reviewed by: dim
Obtained from: Clang commit r266123
MFC after: 3 days
Relnotes: yes
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D7250
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.
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
Instead of changing the whole course to another POSIX-permitted way
for consistency and uniformity I decide to completely ignore missing
regex fucntionality and focus on fixing bugs in what we have now,
too many small obstacles we have choicing other way, counting ports.
Corresponding libc changes are backed out in r302824.
Instead of changing the whole course to another POSIX-permitted way
for consistency and uniformity I decide to completely ignore missing
regex fucntionality and focus on fixing bugs in what we have now,
too many small obstacles we have choicing other way, counting ports.
Corresponding libc changes are backed out in r302824.
Instead of changing the whole course to another POSIX-permitted way
for consistency and uniformity I decide to completely ignore missing
regex fucntionality and focus on fixing bugs in what we have now,
too many small obstacles we have choicing other way, counting ports.
Corresponding libc changes are backed out in r302824.
Instead of trying to expand whole range at regcomp() stage as we do,
GNU regex allocates separate ranges [start,end] set each character
is checked against, so collation is possible and turned on for ranges here.
When something like that will be implemented or our obsoleted regex code
will be replaced to something like TRE, and in case we decide to use
collation in [a-z] ranges, all changes related to r302512 can be backed out,
but now we need consistency.
glob() here too.
I try to keep the change minimal to not touch contribed code much.
I'll send it upstream when it will be merged to the main branches,
but we need this change now here.
I'll try to keep the change very minimal to not touch contribed code much.
I'll send it upstream when it will be merged to main branches,
but we need the change right now here.
This may be reworked upstream but in the interim should address the
stack usage issue reported in the PR.
PR: 206384
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
The key improvement is that it may be built without cross-unwinding
support, which significantly reduces the stack space requirement.
MFC after: 1 week
Relnotes: yes
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D7123
This fixes the 02 testcases on i386 (at least), and may fix the testcases
in general on 32-bit platforms
Differential Revision: https://reviews.freebsd.org/D7052
Approved by: phil (maintainer)
Approved by: re (gjb)
Reported by: asomers
Reviewed by: phil
Submitted by: phil
Sponsored by: EMC / Isilon Storage Division
Sync libarchive with vendor, bugfixes for tests:
- fix tests on filesystems without birthtime support, e.g. UFS1 (1)
- vendor issue #729: avoid use of C99 for-scope declarations in
test_write_format_gnutar_filenames.c
MFC after: 1 week
PR: 204157 (1)
Approved by: re (hrs)
Otherwise the output is buffered and it appears that make is stuck on something
long-running. This problem is not present with -j as it uses different
code that was already flushing.
Discussed with: sjg
Approved by: re (blanket, META_MODE)
Sponsored by: EMC / Isilon Storage Division
Update libarchive to 3.2.1 (bugfix and security fix release)
List of vendor fixes:
- fix exploitable heap overflow vulnerability in Rar decompression
(vendor issue 719, CVE-2016-4302, TALOS-2016-0154)
- fix exploitable stack based buffer overflow vulnebarility in mtree
parse_device functionality (vendor PR 715, CVE-2016-4301, TALOS-2016-0153)
- fix exploitable heap overflow vulnerability in 7-zip read_SubStreamsInfo
(vendor issue 718, CVE-2016-4300, TALOS-2016-152)
- fix integer overflow when computing location of volume descriptor
(vendor issue 717)
- fix buffer overflow when reading a crafred rar archive (vendor issue 521)
- fix possible buffer overflow when reading ISO9660 archives on machines
where sizeof(int) < sizeof(size_t) (vendor issue 711)
- tar and cpio should fail if an input file named on the command line is
missing (vendor issue 708)
- fix incorrect writing of gnutar filenames that are exactly 512 bytes
long (vendor issue 682)
- allow tests to be run from paths that are equal or longer than 128
characters (vendor issue 657)
- add memory allocation errors in archive_entry_xattr.c (vendor PR 603)
- remove dead code in archive_entry_xattr_add_entry() (vendor PR 716)
- fix broken decryption of ZIP files (vendor issue 553)
- manpage style, typo and description fixes
Post-3.2.1 vendor fixes:
- fix typo in cpio version reporting (Vendor PR 725, 726)
- fix argument range of ctype functions in libarchive_fe/passphrase.c
- fix ctype use and avoid empty loop bodies in WARC reader
MFC after: 1 week
Security: CVE-2016-4300, CVE-2016-4301, CVE-2016-4302
Approved by: re (kib)
In addition to adding initial support for the ipfilter
packet filtering system, wrap a few long lines, perform
whitespace cleanup and sync with upstream changes made
in NetBSD.
Submitted by: cy
Reviewed by: cy
Approved by: re (hrs)
Relnotes: YES
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D6823
Detect /usr/share/dict/words the "right way" by using require.files instead of
the hacked up attempt in the dict(..) function, which didn't work properly on
systems where MK_DICT == no.
MFC after: 1 week
Sponsored by: EMC / Isilon Storage Division
The PRNG was changed in r300953/r300956, and subsequently, the numbers
generated have changed. This is expected ABI breakage per ache
X-MFC with: r300953, r300956
Tested with: amd64, i386
Sponsored by: EMC / Isilon Storage Division
of Capser and should use openat(2) unconditionally on FreeBSD.
openat(2) is mandatory when sandboxed with Capsicum, but still works
in the absence of Capsicum.
Reviewed by: AllanJude
POSIX basename() and dirname() are allowed to overwrite the input
buffer. The advantage of implementing it that way is that the functions
can be thread-safe, as they don't store the result in a global buffer.
It looks like ATF wants to call basename() and dirname() in the
non-standard way where the argument is of type "const char *". This
change disables the calls to basename() and dirname(), which only seems
to affect the formatting of some rare debug/error messages.
Reviewed by: ngie
Differential Revision: https://reviews.freebsd.org/D6627
I got this wrong and the coverity report doesn't match the NetBSD change,
which was thought for a different version.
The change wouldn't hurt but let's wait until upstream figures this out.
This adds stravis() and some new encoding flags VIS_SHELL, VIS_META,
and VIS_NOLOCALE.
Assorted cleanups and fixes includeing a manpage typo[0].
PR: 210013 [0]
Submitted by: pi [0]
