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
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
- Two changes to encoder options:
encoder options may use plus or colon, but only one
encoder names can be specified as "@name"
This results in the syntax:
df --libxo @csv:no-header:leafs=name.available-blocks /
- If xo_set_program is called before xo_parse_args, honor the requested value
- add xo_errorn* function; repair newline-adding-on-xo_error bug
- test programs now use fixed name, since linux libtool prefixs "lt-"
- Fix "horse butt" comment in source code
- update test cases
PR: 242686
Add 8548 CPU definition and attributes
8548 CPU is GCC's name for the e500v2, so accept this in clang. The
e500v2 doesn't support lwsync, so define __NO_LWSYNC__ for this as
well, as GCC does.
Differential Revision: https://reviews.llvm.org/D67787
Merge commit ff0311c4b from llvm git (by Justin Hibbits):
[PowerPC]: Add powerpcspe target triple subarch component
Summary:
This allows the use of '-target powerpcspe-unknown-linux-gnu' or
'powerpcspe-unknown-freebsd' to be used, instead of '-target
powerpc-unknown-linux-gnu -mspe'.
Reviewed By: dim
Differential Revision: https://reviews.llvm.org/D72014
Merge commit ba91dffaf from llvm git (by Fangrui Song):
[Driver][PowerPC] Move powerpcspe logic from cc1 to Driver
Follow-up of D72014. It is more appropriate to use a target feature
instead of a SubTypeArch to express the difference.
Reviewed By: #powerpc, jhibbits
Differential Revision: https://reviews.llvm.org/D72433
commit 36eedfcb3 from llvm git (by Justin Hibbits):
[PowerPC] Fix powerpcspe subtarget enablement in llvm backend
Summary:
As currently written, -target powerpcspe will enable SPE regardless
of disabling the feature later on in the command line. Instead,
change this to just set a default CPU to 'e500' instead of a generic
CPU.
As part of this, add FeatureSPE to the e500 definition.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D72673
These are needed to unbreak the build for powerpcspe.
Requested by: jhibbits
MFC after: 1 week
[MIPS][ELF] Use PC-relative relocations in .eh_frame when possible
When compiling position-independent executables, we now use
DW_EH_PE_pcrel | DW_EH_PE_sdata4. However, the MIPS ABI does not define a
64-bit PC-relative ELF relocation so we cannot use sdata8 for the large
code model case. When using the large code model, we fall back to the
previous behaviour of generating absolute relocations.
With this change clang-generated .o files can be linked by LLD without
having to pass -Wl,-z,notext (which creates text relocations).
This is simpler than the approach used by ld.bfd, which rewrites the
.eh_frame section to convert absolute relocations into relative references.
I saw in D13104 that apparently ld.bfd did not accept pc-relative relocations
for MIPS ouput at some point. However, I also checked that recent ld.bfd
can process the clang-generated .o files so this no longer seems true.
Reviewed By: atanasyan
Differential Revision: https://reviews.llvm.org/D72228
Merge commit 8e8ccf47 from llvm git (by me)
[MIPS] Don't emit R_(MICRO)MIPS_JALR relocations against data symbols
The R_(MICRO)MIPS_JALR optimization only works when used against functions.
Using the relocation against a data symbol (e.g. function pointer) will
cause some linkers that don't ignore the hint in this case (e.g. LLD prior
to commit 5bab291) to generate a relative branch to the data symbol
which crashes at run time. Before this patch, LLVM was erroneously emitting
these relocations against local-dynamic TLS function pointers and global
function pointers with internal visibility.
Reviewers: atanasyan, jrtc27, vstefanovic
Reviewed By: atanasyan
Differential Revision: https://reviews.llvm.org/D72571
These two changes should allow using lld for MIPS64 (and maybe also MIPS32)
by default.
The second commit is not strictly necessary for clang+lld since LLD9 will
not perform the R_MIPS_JALR optimization (it was only added for 10) but it
is probably required in order to use recent ld.bfd.
Reviewed By: dim, emaste
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D23203
