Restore functionality of --sysroot on FreeBSD after b18cb9c47
After b18cb9c47, clang would sometimes prefer the host C++ includes
(e.g. in /usr/include/c++/v1) before those specified via --sysroot.
While this behavior may be desirable on Linux, it is not so on
FreeBSD, where we make extensive use of --sysroot during the build of
the base system. In that case, clang must *not* search outside the
sysroot, except for its own internal headers.
Add an override addLibCxxIncludePaths() to restore the old behavior,
which is to simply append /usr/include/c++/v1 to the specified
sysroot. While here, apply clang-format to the FreeBSD specific
toolchain files.
Fixes PR44923.
Fix a -Wbitwise-conditional-parentheses warning in
_LIBUNWIND_ARM_EHABI libunwind builds
```
src/UnwindCursor.hpp:1344:51: error: operator '?:' has lower precedence than '|'; '|' will be evaluated first [-Werror,-Wbitwise-conditional-parentheses]
_info.flags = isSingleWordEHT ? 1 : 0 | scope32 ? 0x2 : 0; // Use enum?
~~~~~~~~~~~ ^
src/UnwindCursor.hpp:1344:51: note: place parentheses around the '|' expression to silence this warning
_info.flags = isSingleWordEHT ? 1 : 0 | scope32 ? 0x2 : 0; // Use enum?
^
( )
src/UnwindCursor.hpp:1344:51: note: place parentheses around the '?:' expression to evaluate it first
_info.flags = isSingleWordEHT ? 1 : 0 | scope32 ? 0x2 : 0; // Use enum?
^
( )
```
But `0 |` is a no-op for either of those two interpretations, so I
think what was meant here was
```
_info.flags = (isSingleWordEHT ? 1 : 0) | (scope32 ? 0x2 : 0); // Use enum?
```
Previously, if `isSingleWordEHT` was set, bit 2 would never be set.
Now it is. From what I can tell, the only thing that checks these
bitmask is ProcessDescriptors in Unwind-EHABI.cpp, and that only
cares about bit 1, so in practice this shouldn't have much of an
effect.
Differential Revision: https://reviews.llvm.org/D73890
This fixes the above errors when building libunwind for arm variants.
The hack in question is intended to workaround seemingly bogus #line markers
in cpp output. As far as I can tell, llvm cpp doesn't do this by default, so
there's no reason to add -P.
In our /bin/sh, the main incantation should be placed in a sub-shell in
order to properly pipe the output to fgrep.
The main motivation for this change is admittedly to stop emitting the noise
about clang not being gcc in make -s buildworld
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D22952
Presumably a bool definition is obtained via header contamination on
FreeBSD-CURRENT. Found while trying to upstream FreeBSD addr2line
changes - the FreeBSD 11.2 CI build failed there.
Reported by: Cirrus-CI, upstream ELF Tool Chain
MFC with: r357844
Sponsored by: The FreeBSD Foundation
Update libarchive to 3.4.2
Relevant vendor changes:
PR #1289: atomic extraction support (bsdtar -x --safe-writes)
PR #1308: big endian fix for UTF16 support in LHA reader
PR #1326: reject RAR5 files that declare invalid header flags
Issue #987: fix support 7z archive entries with Delta filter
Issue #1317: fix compression output buffer handling in XAR writer
Issue #1319: fix uname or gname longer than 32 characters in pax writer
Issue #1325: fix use after free when archiving hardlinks in ISO9660 or XAR
Use localtime_r() and gmtime_r() instead of localtime() and gmtime()
X-MFC-With: r356212,r356365,r356416
MFC after: 1 week
Libarchive 3.4.2
Relevant vendor changes:
PR #1289: atomic extraction support (bsdtar -x --safe-writes)
PR #1308: big endian fix for UTF16 support in LHA reader
PR #1326: reject RAR5 files that declare invalid header flags
Issue #987: fix support 7z archive entries with Delta filter
Issue #1317: fix compression output buffer handling in XAR writer
Issue #1319: fix uname or gname longer than 32 characters in pax writer
Issue #1325: fix use after free when archiving hardlinks in ISO9660 or XAR
Use localtime_r() and gmtime_r() instead of localtime() and gmtime()
The version that ended upstream was ultimately slightly different than the
version committed here; notably, statvfs() is used but it's redefined
appropriately to statfs() on FreeBSD since we don't provide the fstypename
for the former interface.
The revokex test does not work when the scratch directory is created on NFS.
Given the nature of NFS, it likely can never work without looking like a
security hole since O_SEARCH would rely on the server knowing that the
directory did have +x at the time of open and that it's OK for it to have
been revoked based on POSIX specification for O_SEARCH.
This does mean that O_SEARCH is only partially functional on NFS in general,
but I suspect the execute bit getting revoked in the process is likely not
common.
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D23573
The RCSID data was wrong, so this is effectively a record-only merge
with correction of said data. No further changes should be needed in this
area, as we've now upstreamed our local changes to this specific test.
In FreeBSD's O_SEARCH implementation, O_SEARCH in conjunction with O_RDWR or
O_WRONLY is explicitly rejected. In this case, O_RDWR was not necessary
anyways as the file will get created with or without it.
This was submitted upstream as misc/54940 and committed in rev 1.8 of the
file.
Coverity correctly reports this as a resource leak. It's an admittedly minor
one, but plug it anyways.
This has been submitted upstream as misc/54939.
CID: 978288
The caller of dump_object() is responsible for opening the file, let it
be responsible for closing too.
CID: 1411588
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
The callers only check whether the returned pointer is non-NULL, so this
was harmless in practice, but change the return value to guard against
the issue.
CID: 1411597
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
We should really create the output file in the same directory as the
destination file so that rename() works. This will be done in a future
change as part of some work to run in capability mode.
CID: 1262523
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
The code clearly meant to resize the buffer in the case where a section
was backed by multiple data descriptors.
In practice this shouldn't have been a problem since libelf would return
a single data descriptor for each section in a newly opened file.
CID: 1262522
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
All callers pass a non-NULL pointer, and otherwise it was possible to
leak memory if the abbrev was not added to a CU.
CID: 1193365
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
All callers of _dwarf_add_expr() and _dwarf_expr_into_block() pass a
non-NULL expr pointer, and these functions assume that expr is non-NULL
anyway.
CID: 1193305, 1193306
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
sqlite3-3.30.1 (3300100), as it causes svnlite segfaults on PowerPC,
resulting in corruption.
Reported by: Mark Millard <marklmi at yahoo.com>
Francis Little <oggy at farscape.co.uk>
Previously, addr2line would sequentially search all CUs for each input
address. For some uses, notably syzkaller's code coverage map generator,
this was extremely slow. Add a CU cache into which entries are added
following a successful lookup, and search the cache before falling back
to a scan. When translating a large number of addresses this yields
slightly better performance than GNU addr2line.
Garbage-collect an unused hash table which appears to have been intended
for the same purpose. A hash table doesn't seem particularly suitable
since each CU spans a range of addresses.
Submitted by: Tiger Gao <tig@freebsdfoundation.org>
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D23418
O_SEARCH is defined by POSIX [0] to open a directory for searching, skipping
permissions checks on the directory itself after the initial open(). This is
close to the semantics we've historically applied for O_EXEC on a directory,
which is UB according to POSIX. Conveniently, O_SEARCH on a file is also
explicitly undefined behavior according to POSIX, so O_EXEC would be a fine
choice. The spec goes on to state that O_SEARCH and O_EXEC need not be
distinct values, but they're not defined to be the same value.
This was pointed out as an incompatibility with other systems that had made
its way into libarchive, which had assumed that O_EXEC was an alias for
O_SEARCH.
This defines compatibility O_SEARCH/FSEARCH (equivalent to O_EXEC and FEXEC
respectively) and expands our UB for O_EXEC on a directory. O_EXEC on a
directory is checked in vn_open_vnode already, so for completeness we add a
NOEXECCHECK when O_SEARCH has been specified on the top-level fd and do not
re-check that when descending in namei.
[0] https://pubs.opengroup.org/onlinepubs/9699919799/
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D23247
This construction used some relatively slow design involving SHA2; even if
it were fed real entropy (unclear; external to the design), it did not
handle fork in a safe way, and it was difficult to audit for correctness.
So just rip it out and use the very simple and known-correct arc4random(3)
interface in its place.
In apr_vformatter, the variable buf was declared inside a limited scope
region, but a pointer to it is leaked outside of that region and used
later. This is undefined behavior. Fix by moving the buf variable to
function scope.
Reported by: Coverity
CID: 1192541
[ELF] Map the ELF header at imageBase
If there is no readonly section, we map:
* The ELF header at imageBase+maxPageSize
* Program headers at imageBase+maxPageSize+sizeof(Ehdr)
* The first section .text at imageBase+maxPageSize+sizeof(Ehdr)+sizeof(program headers)
Due to the interaction between Writer<ELFT>::fixSectionAlignments and
LinkerScript::allocateHeaders,
`alignDown(p_vaddr(R PT_LOAD)) = alignDown(p_vaddr(RX PT_LOAD))`.
The RX PT_LOAD will override the R PT_LOAD at runtime, which is not ideal:
```
// PHDR at 0x401034, should be 0x400034
PHDR 0x000034 0x00401034 0x00401034 0x000a0 0x000a0 R 0x4
// R PT_LOAD contains just Ehdr and program headers.
// At 0x401000, should be 0x400000
LOAD 0x000000 0x00401000 0x00401000 0x000d4 0x000d4 R 0x1000
LOAD 0x0000d4 0x004010d4 0x004010d4 0x00001 0x00001 R E 0x1000
```
* createPhdrs allocates the headers to the R PT_LOAD.
* fixSectionAlignments assigns `imageBase+maxPageSize+sizeof(Ehdr)+sizeof(program headers)` (formula: `alignTo(dot, maxPageSize) + dot % config->maxPageSize`) to addrExpr of .text
* allocateHeaders computes the minimum address among SHF_ALLOC sections, i.e. addr(.text)
* allocateHeaders sets address of ELF header to `addr(.text)-sizeof(Ehdr)-sizeof(program headers) = imageBase+maxPageSize`
The main observation is that when the SECTIONS command is not used, we
don't have to call allocateHeaders. This requires an assumption that
the presence of PT_PHDR and addresses of headers can be decided
regardless of address information.
This may seem natural because dot is not manipulated by a linker script.
The other thing is that we have to drop the special rule for -T<section>
in `getInitialDot`. If -Ttext is smaller than the image base, the headers
will not be allocated with the old behavior (allocateHeaders is called)
but always allocated with the new behavior.
The behavior change is not a problem. Whether and where headers are
allocated can vary among linkers, or ld.bfd across different versions
(--enable-separate-code or not). It is thus advised to use a linker
script with the PHDRS command to have a consistent behavior across
linkers. If PT_PHDR is needed, an explicit --image-base can be a simpler
alternative.
Differential Revision: https://reviews.llvm.org/D67325
llvm-svn: 371957
This causes "ld: error: output file too large: 18446744073707016908
bytes" when linking our loader_4th and loader_lua. Clearly, something
is wrong when using -Ttext 0x0: I will file an upstream bug report for
this.
Fix the following -Werror warning from clang 10.0.0 in binutils:
contrib/binutils/bfd/peicode.h:1356:3: error: misleading indentation; statement is not part of the previous 'if' [-Werror,-Wmisleading-indentation]
if (efi)
^
contrib/binutils/bfd/peicode.h:1353:8: note: previous statement is here
if (pe_arch (bfd_target_efi_arch (*target_ptr)) != arch)
^
contrib/binutils/bfd/peicode.h:1370:3: error: misleading indentation; statement is not part of the previous 'if' [-Werror,-Wmisleading-indentation]
if (!efi)
^
contrib/binutils/bfd/peicode.h:1367:8: note: previous statement is here
if (pe_arch (bfd_target_pei_arch (*target_ptr)) != arch)
^
MFC after: 3 days
contrib/binutils/bfd/peicode.h:1356:3: error: misleading indentation; statement is not part of the previous 'if' [-Werror,-Wmisleading-indentation]
if (efi)
^
contrib/binutils/bfd/peicode.h:1353:8: note: previous statement is here
if (pe_arch (bfd_target_efi_arch (*target_ptr)) != arch)
^
contrib/binutils/bfd/peicode.h:1370:3: error: misleading indentation; statement is not part of the previous 'if' [-Werror,-Wmisleading-indentation]
if (!efi)
^
contrib/binutils/bfd/peicode.h:1367:8: note: previous statement is here
if (pe_arch (bfd_target_pei_arch (*target_ptr)) != arch)
^
MFC after: 3 days
The current code clearly intended for these to be octal based on the values
used, but the octal prefix was forgotten. Add it now for correctness, but
note that we don't currently execute these tests.
This has been submitted upstream as misc/54902, so I've omitted the standard
FreeBSD markers that we tend to put into netbsd-tests for upstream-candidate
identification.
Reviewed by: ngie
MFC after: 3 days
