[RISCV] Don't force Local Exec TLS for non-PIC
Summary:
Forcing Local Exec TLS requires the use of copy relocations. Copy
relocations need special handling in the runtime linker when being
used against TLS symbols, which is present in glibc, but not in
FreeBSD nor musl, and so cannot be relied upon. Moreover, copy
relocations are a hack that embed the size of an object in the ABI
when it otherwise wouldn't be, and break protected symbols (which are
expected to be DSO local), whilst also wasting space, thus they
should be avoided whenever possible. As discussed in D70398, RISC-V
should move away from forcing Local Exec, and instead use Initial
Exec like other targets, with possible linker relaxation to follow.
The RISC-V GCC maintainers also intend to adopt this
more-conventional behaviour (see
https://github.com/riscv/riscv-elf-psabi-doc/issues/122).
Reviewers: asb, MaskRay
Reviewed By: MaskRay
Subscribers: emaste, krytarowski, hiraditya, rbar, johnrusso,
simoncook, sabuasal, niosHD, kito-cheng, shiva0217, zzheng,
edward-jones, rogfer01, MartinMosbeck, brucehoult, the_o, rkruppe,
PkmX, jocewei, psnobl, benna, Jim, lenary, s.egerton, pzheng,
sameer.abuasal, apazos, llvm-commits, bsdjhb
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D70649
This is a prerequisite for building and linking hard- and soft-float
riscv worlds with clang and lld.
Requested by: jhb
MFC after: 1 week
X-MFC-With: r353358
[RISCV] Fix evaluation of %pcrel_lo
The following testcase
function:
.Lpcrel_label1:
auipc a0, %pcrel_hi(other_function)
addi a1, a0, %pcrel_lo(.Lpcrel_label1)
.p2align 2 # Causes a new fragment to be emitted
.type other_function,@function
other_function:
ret
exposes an odd behaviour in which only the %pcrel_hi relocation is
evaluated but not the %pcrel_lo.
$ llvm-mc -triple riscv64 -filetype obj t.s | llvm-objdump -d -r -
<stdin>: file format ELF64-riscv
Disassembly of section .text:
0000000000000000 function:
0: 17 05 00 00 auipc a0, 0
4: 93 05 05 00 mv a1, a0
0000000000000004: R_RISCV_PCREL_LO12_I other_function+4
0000000000000008 other_function:
8: 67 80 00 00 ret
The reason seems to be that in RISCVAsmBackend::shouldForceRelocation
we only consider the fragment but in RISCVMCExpr::evaluatePCRelLo we
consider the section. This usually works but there are cases where
the section may still be the same but the fragment may be another
one. In that case we end forcing a %pcrel_lo relocation without any
%pcrel_hi.
This patch makes RISCVAsmBackend::shouldForceRelocation use the
section, if any, to determine if the relocation must be forced or
not.
Differential Revision: https://reviews.llvm.org/D60657
This is a prerequisite for building and linking hard- and soft-float
riscv worlds with clang and lld.
Requested by: jhb
MFC after: 1 week
X-MFC-With: r353358
GCC issues the warning, but with LLVM it is fatal- no matching .cprestore
with .cpload. Reserve some place on the stack and and add the proper
.cprestore to pair it with.
nop added in the !o32 branch to fill out delay slot instruction, just in
case.
Reviewed by: arichardson
Differential Revision: https://reviews.freebsd.org/D21697
r356147 removed a vm_page_activate() call, but this is required to
ensure that pages end up in the page queues in the first place.
Restore the pre-r356157 logic. Now, without the page lock, the
vm_page_active() check is racy, but this race is harmless.
Reviewed by: alc, kib
Reported and tested by: pho
Differential Revision: https://reviews.freebsd.org/D23024
More MACHINE_CPUARCH/MACHINE_ARCH cases enable these options than
disable them, and several of them have work in progress to switch over.
Thus, invert the sense of the test and list cases not using LLD as the
exceptions.
There were a few special cases for arm v5, such as disabling LLDB due to
the lack of 64-bit atomic operations. Now that arm has been retired (as
of r356263) we can simplify the options logic somewhat.
After increasing WARNS, building WITHOUT_TCP_WRAPPERS failed because of
some unused variables.
Reported by: Cirrus-CI (against my WIP branch)
MFC with: r356248
Sponsored by: The FreeBSD Foundation
This is a re-apply r356249 with changes to make GCC happy.
This utility was initially written for FAT12/16, which were inherently
small. When FAT32 support was added, the old data structure and
algorithms remain used with minimal changes.
With growing size of FAT32 media, the current data structure that
requires 4 32-bit variables per each FAT32 table entry would consume up
to 4 GiB of RAM, which can be too big for systems with limited RAM
available.
Address this by taking a different approach of validating the FAT.
The FAT is essentially a set of linked lists of chains that was
referenced by directory entries, and the checker needs to make sure that
the linked chains of clusters do not have cross-linked chains, and every
chain were referenced by one and only one directory entry. Instead of
keeping track of the chain's 'head' cluster number, the size of the
chain, the used status of the chain and the "next" pointer which is
content of the FAT table, we create accessors for the FAT table data
for the "next" pointer, and keep only one bit to indicate if the
current cluster is a 'head' node of a cluster chain, in a bitmap.
We further overhaul the FAT checker to find out the possible head nodes
by excluding ones that are not (in other words, nodes that have some
other nodes claiming them as the next node) instead of marking the head
nodes for each node on the chain. This approach greatly reduced the
complexiety of computation from O(N^2) worst case, to an O(N) scan for
worst case. The file (cluster chain) length is not useful for the FAT
checker, so don't bother to calculate them in the FAT checker and
instead leave the task to the directory structure check, at which point
we would have non-crossed cluster chains, and we are guaranteed that
each cluster will be visited for at most one time.
When checking the directory structures, we use the head node indicator
to as the visited (used) flag: every cluster chain can only be
referenced by one directory entry, so we clear them when calculating
the length of the chain, and we can immediately tell if there are
anomalies in the directory entry.
As a result, the required RAM size is now 1 bit per each entry of
the FAT table, plus memory needed to hold the FAT table in memory,
instead of 16 bytes (=128 bits) per each entry. For FAT12 and FAT16,
we will load the whole FAT table into memory as they are smaller than
128KiB, and for FAT32, we first attempt to mmap() it into memory, and
when that fails, we would fall back to a simple LRU cache of 4 MiB of
RAM.
sbin/fsck_msdosfs/boot.c:
- Added additional sanity checks for valid FAT32/FAT16/FAT12 cluster
number.
- FAT32: check if root directory starts with a valid cluster number,
moved from dir.c. There is no point to proceed if the filesystem
is already damaged beyond repair.
sbin/fsck_msdosfs/check.c:
- Combine phase 1 and phase 2, now that the readfat() is able to
detect cross chains.
sbin/fsck_msdosfs/dir.c:
- Refactor code to use FAT accessor instead of accessing the internal
representation of FAT table.
- Make use of the cluster chain head bitmap.
- Clarify and simplify directory entry check, remove unnecessary
checks that are would be done at a later time (for example, whether
the directory's second cluster is a valid one, which is examined
more throughly in a later checkchain() and does not prevent us
from proceeding further).
sbin/fsck_msdosfs/dosfs.h:
- Remove internal representation of FAT table, which is replaced by
the head bitmap that is opaque to other code.
- Added a special CLUST_DEAD cluster type to indicate errors.
sbin/fsck_msdosfs/ext.h:
- Added a flag that overrides mmap(2) setting. The corresponding
command line option, -M is intentionally undocumented as we do not
expect users to need it.
- Added accessors for FAT table and convert existing interface to use
it.
sbin/fsck_msdosfs/fat.c:
- Added head bitmap to represent whether a cluster is a head cluster.
- Converted FAT internal representation to accessors.
- Implemented a LRU cache for FAT32 when mmap(2) should not or can not
be used.
- _readfat: Attempt a mmap(2) and fall back to regular read for
non-FAT32 file systems; use the LRU cache for FAT32 and prepopulate
the cache with the first 4MiB of the entries.
- readfat: Added support of head bitmap and use the population scan to
detect bogus chains.
- clusterdiff: removed, FATs are copied from the checked copy via
writefat()/copyfat().
- checkchain: calculates the length of a cluster chain and make sure
that it ends with a valid EOF marker.
- clearchain: follow and clear a chain and maintain the free cluster
count.
- checklost: convert to use head bitmap. At the end of all other scans,
the remaining 'head' nodes are leaders of lost cluster chains.
sbin/fsck_msdosfs/fat.c:
- Added a new -M option which is intentionally undocumented, to disable
the use of mmap().
Reviewed by: kevlo
MFC after: 1 month
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D22965
While changing link state in iflib_link_state_change(), queues are
marked as IFLIB_QUEUE_IDLE to disable watchdog. Currently, iflib_timer()
watchdog does not check for previous queue status before marking it as
IFLIB_QUEUE_HUNG.
This patch adds check of queue status before marking it as hung.
Signed-off-by: Piotr Pietruszewski <piotr.pietruszewski@intel.com>
PR: 239240
Submitted by: Piotr Pietruszewski <piotr.pietruszewski@intel.com>
Reported by: ultima@
Reviewed by: gallatin@, erj@
MFC after: 3 days
Sponsored by: Intel Corporation
Differential Revision: https://reviews.freebsd.org/D21712
Add a privilege check to the ixl_handle_nvmupd_cmd function, ensuring
that only privileged users are allowed to access the NVM update
interface.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Submitted by: Jacob Keller <jacob.e.keller@intel.com>
Reported by: markj@
Reviewed by: markj@, erj@, jeffrey.e.pieper@intel.com
MFC after: 3 days
Sponsored by: Intel Corporation
Differential Revision: https://reviews.freebsd.org/D22870
This is a lock-based emulation of 64-bit atomics for kernel use, split off
from an earlier patch by jhibbits.
This is needed to unblock future improvements that reduce the need for
locking on 64-bit platforms by using atomic updates.
The implementation allows for future integration with userland atomic64,
but as that implies going through sysarch for every use, the current
status quo of userland doing its own locking may be for the best.
Submitted by: jhibbits (original patch), kevans (mips bits)
Reviewed by: jhibbits, jeff, kevans
Differential Revision: https://reviews.freebsd.org/D22976
The goal here is to make it so applications can take the rights one would
normally get by calling caph_limit_stream() on a descriptor and build on
them as needed.
The tentatively planned use-case is an application that takes a socket and
hooks it up to std{err,out,in} for a fork()d child. It may be feasible to
apply limitations to such descriptors as long as it's a superset of those
normally applied to stdio.
Reviewed by: markj, oshobo (prior version; sans manpage addition)
Differential Revision: https://reviews.freebsd.org/D22993
The fdt attachment for this heavily relies on extres for clk work. This
unbreaks the build for mips XLPN32/XLP, which have pci/fdt but no need for
this fdt attachment.
This will soon be a dependency for machine/atomic.h on mips with the
introduction of 64-bit atomics; the scope here is pretty narrow, so throw it
here in the header just before systm.h, which includes machine/atomic.h
When activated in direct exec mode, kernel-provided AT_EXECPATH points
to the interpreter. We need to recalculate auxv to point to the
string with the path to the executable which is actually executed.
The somewhat problematic case is when the executable path is relative
and either $PATH use is not enabled or it contains '/' so $PATH search
is not performed. In this case resulting AT_EXECPATH is relative, I
might fix this later.
Reported and reviewed by: rstone
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D22894
and make it usable outside of kern_umtx.c. To be used in several
future changes.
Discussed with: markj
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
The freebsd-binutils and freebsd-gcc* packages install toolchain
makefiles to /usr/share/toolchains rather than LOCALBASE.
Reviewed by: bapt
Differential Revision: https://reviews.freebsd.org/D22985
Its use of the page lock is incorrect, and it is not used by the DRM
modules.
Reviewed by: hselasky
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D23002
The page daemon loops may move pages back to the active queue if
references are detected. In this case we must take care to clear
existing queue operation flags. In particular, PGA_REQUEUE_HEAD may be
set, and that flag is only valid if the page belongs to the inactive
queue.
Also fix a bug in the active queue scan where we were updating "old"
instead of "new". This would only have been hit in rare cases where the
page moved out of the active queue after the beginning of the scan.
Reported by: Bob Prohaska, Idwer Vollering
Tested by: Idwer Vollering
Reviewed by: alc, kib
Differential Revision: https://reviews.freebsd.org/D23001
When removing a boot environment iterate over the dependents and process the
snapshots by grabbing any clones. Promote the clones we found and then
remove the target environment.
This fixes the ability to destroy a boot environment when it has been used
to spawn one or more other boot environments.
PR: 242592
Submitted by: Wes Maag <jwmaag gmail com> (with changes by myself)
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D22953
An i2c bus can be divided into segments which can be selectively connected
and disconnected from the main bus. This is usually done to enable using
multiple slave devices having the same address, by isolating the devices
onto separate bus segments, only one of which is connected to the main bus
at once.
There are several types of i2c bus muxes, which break down into two general
categories...
- Muxes which are themselves i2c slaves. These devices respond to i2c
commands on their upstream bus, and based on those commands, connect
various downstream buses to the upstream. In newbus terms, they are both
a child of an iicbus and the parent of one or more iicbus instances.
- Muxes which are not i2c devices themselves. Such devices are part of the
i2c bus electrically, but in newbus terms their parent is some other
bus. The association with the upstream bus must be established by
separate metadata (such as FDT data).
In both cases, the mux driver has one or more iicbus child instances
representing the downstream buses. The mux driver implements the iicbus_if
interface, as if it were an iichb host bridge/i2c controller driver. It
services the IO requests sent to it by forwarding them to the iicbus
instance representing the upstream bus, after electrically connecting the
upstream bus to the downstream bus that hosts the i2c slave device which
made the IO request.
The net effect is automatic mux switching which is transparent to slaves on
the downstream buses. They just do i2c IO they way they normally do, and the
bus is electrically connected for the duration of the IO and then idled when
it is complete.
The existing iicbus_if callback() method is enhanced so that the parameter
passed to it can be a struct which contains a device_t for the requesting
bus and slave devices. This change is done by adding a flag that indicates
the extra values are present, and making the flags field the first field of
a new args struct. If the flag is set, the iichb or mux driver can recast
the pointer-to-flags into a pointer-to-struct and access the extra
fields. Thus abi compatibility with older drivers is retained (but a mux
cannot exist on the bus with the older iicbus driver in use.)
A new set of core support routines exists in iicbus.c. This code will help
implement mux drivers for any type of mux hardware by supplying all the
boilerplate code that forwards IO requests upstream. It also has code for
parsing metadata and instantiating the child iicbus instances based on it.
Two new hardware mux drivers are added. The ltc430x driver supports the
LTC4305/4306 mux chips which are controlled via i2c commands. The
iic_gpiomux driver supports any mux hardware which is controlled by
manipulating the state of one or more gpio pins. Test Plan
Tested locally using a variety of mux'd bus configurations involving both
ltc4305 and a homebrew gpio-controlled mux. Tested configurations included
cascaded muxes (unlikely in the real world, but useful to prove that 'it all
just works' in terms of the automatic switching and upstream forwarding of
IO requests).
This is needed when the driver is compiled into the kernel.
When compiled as a module this will be called from another
code path as we also depend on ofw_spibus.
MFC after: 1 week
- Drop mention of _LP64. FreeBSD's source generally uses __LP64__
instead of _LP64, and the relevant macros are better covered in the
"Predefined Macros" section.
- Fix a noun/verb disagreement.
Reviewed by: emaste
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D22975
SCTP_PEER_ADDR_PARAMS socket option. The code in the stack assumes
sane values for the MTU.
This issue was found by running an instance of syzkaller.
MFC after: 1 week
command line option. Thanks to the removal of unnecessary information and
the organization into columns, this helps the output be more legible on
both 80 column displays and non-80 column displays. imp@ provided the
idea on this.
Since rS330365, there has been no particular reason for libofw to be in a
subdirectory of ofw. Move libofw up a level to make it fit in better with
the other top level libraries.
Also add a LIBOFWSRC to stand/defs.mk to match what all the other
libraries are doing.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D23000
TARGET=arm now defaults to TARGET_ARCH=armv7
TARGET_ARCH=arm is no longer valid.
Bump __FreeBSD_version to 1300073
Tested with make universe. Any stale LINT-V5 config files remaining in the tree
will fail the universe build. However, LINT-V5 was removed in r355119.
This retirement has been planned since last summer. The armv5 port is fragile:
it works OK for some peeople, and fails badly for others. There's a number of
subtle bugs in busdma, pmap and other MD parts of thee system that present
themselves under load or in unusual circumstances (like fsck after a
crash). stable/8, branched 10 years ago, was the last reliable release. Since
the support burden is larger then the benefit, the consensus view is armv5
should be removed from the tree.
Discussed with: arm@ mailing list and arm developer community.
r23081 introduced kern.dummy oid as a semi ABI compat for kern.maxsockbuf
that was moved to a new namespace. It never functioned as an alias of any
kind and was just returning 0 unconditionally, hence it was probably
provided to keep some 3rd party programmes happy about sysctl(3) not
reporting an error because of non-existing oid.
After nearly 23 years it seems reasonable to just hide it from sysctl(8)
list not to cause unnecessary confusion as for its purpose.
Reported by: Antranig Vartanian <antranigv@freebsd.am>
Reviewed by: kib (mentor)
Approved by: kib (mentor)
Differential Revision: https://reviews.freebsd.org/D22982
