[DWARFLinker] Emit DW_AT_addr_base for units that had none (#219357)
Fix DWARFv5 units that reach the linker without DW_AT_addr_base, as GCC
emits them at -O2. Both linkers rewrite range and location lists into
base_addressx entries, which resolve through DW_AT_addr_base, but they
only ever patch an attribute copied from the input. With nothing to
patch, the classic linker hits the llvm_unreachable in patchAddrBase(),
and the parallel linker writes indices with no base, so the unit's
ranges resolve from address 0.
Add DW_AT_addr_base to every DWARFv5 unit root that lacks one, whatever
its tag, and emit the unit's .debug_addr contribution even when no
address was pooled, so the attribute always points at a table. Update
mode does not rewrite ranges, so nothing is added there.
The tests link a compile unit root and a partial unit root with both
linkers and check the attribute, the address table, the range list and
--verify. The compile unit test also checks that update mode adds no
attribute, and a third test links a unit that pools no address.
[3 lines not shown]
[DAGCombiner] Fold umin(fp_to_uint(x), 0) to 0 (#232231)
`PerformUMinFpToSatCombine` turns `umin(fp_to_uint(x), (2^n)-1)` into
`fp_to_uint_sat`.
When the clamp width is 0 (2^0-1), `n` is also 0, and `getIntegerVT(0)`
then asserts in `IntegerType::get`, which requires a width of at least
1.
Since an unsigned value is never below 0, the `umin`'s result will
always be 0 as well.
[RISCV][P-ext] Use concat_vectors with 0 in widenPackedVectorWithZeros.
This will be legalized and combined to a vector_shuffle. That
shuffle can then be matched to a pack with x0 after #232892.
This changes the zext.w to a pack, but that's not obviously worse.
If we need to canonicalize we can add a DAG combine later.
[RISCV][P-ext] Remove custom lowering of insert_subvector for v2i16/v4i8 on RV64.
This was for handling inserting into a zero vector. After #232892
we let the insert_subvector legalize to a shuffle_vector which we
can then lower as pack.
This changes the codegen from zext.w to pack, but that's not
necessarily worse. If it turns out to be a problem we can
canonicalize pack with zero with a DAGCombine or isel patterns in
the future.
[RISCV][P-ext] Create zero vector rather than bitcasting from i32 0 in lowerINSERT_SUBVECTOR. (#232852)
Teach LowerBUILD_VECTOR to create SPLAT_VECTOR when all operands are the
same to prevent regression.
[RISCV][P-ext] Call tryWidenMaskForShuffle at the end of P extension shuffle lowering. (#232892)
If the shuffle mask has contiguous elements we can try shuffling them
using a large element type.
[flang,unittest] Initialize targets before creating a CompilerInstance. NFC (#233117)
Initialize targets first to register library options before creating a
CompilerInstance.
ZIL replay can apply part of a split WR_NEED_COPY write
After a crash while an fsync() is still writing the log, ZIL replay can
apply the first part of a write without the rest, leaving the write
torn at an arbitrary 8-byte-aligned offset. This exposes a state that
no reader could have observed before the crash: new data up to the
tear, old data after it. While POSIX doesn't specify anything before
fsync() completes, ZFS intends to preserve the atomicity of writes as
much as possible: writes within a single block are intended to be
atomic, with larger writes torn only on recordsize boundaries.
The problem occurs with WR_NEED_COPY TX_WRITE records. When such a
record does not fit in the current log block, zil_lwb_assign() splits
it into several TX_WRITE records in consecutive log blocks. If the
system crashes after the first of those blocks is on disk but before
all of them are, zil_parse() stops at the missing block, but replay
has already applied the pieces before it. Files are affected for
async writes that a later fsync() commits, and for writes of any size
with a slog. Zvols are affected too, where a tear inside a sector
[75 lines not shown]
rumdl: update to 0.3.0.
Changed
2.4–4.7× faster rumdl fmt than 0.2.79 on frozen documentation
snapshots: Cargo (99 files) 4.7×, MkDocs Material (85 files) 2.6×, and
Ruff (16 files) 2.4×. Reusing parsed Markdown and shared source analysis
reduces repeated work. Speedups compare median elapsed times from 31 paired
runs after five warmups on Apple M6: ordinary Rust 1.96.0 release builds,
default threads, warm filesystem cache, and --no-config --no-cache --silent
(--flavor=standard for Cargo/Ruff, --flavor=mkdocs for MkDocs Material).
Output includes the correctness fixes listed below and can differ from 0.2.79.
Code block tools are supported and remain opt-in. Missing tags, missing
active-mode tools and invocations with no tools checked are ignored by default.
An omitted unknown-tag policy inherits on-missing-language-definition,
preserving existing strict configurations. Valid internal cached checks count
as checked; applicable external tools rerun to reflect changes in their own
configuration and environment.
on-missing-language-definition = "warn" now reports uncovered languages;
[134 lines not shown]
Makefile.inc1: Adjust mkimg bootstrap versions
Stream-optimized VMDK support was merged to stable/15 with
__FreeBSD_version 1501504.
Sponsored by: Amazon
vdev_mirror: scrub every copy of a gang block in a sorted scrub
A sorted scrub queues one read per DVA of a block, and each of these
reads carries all of the block's DVAs so that a damaged copy can be
repaired. vdev_mirror_map_init() therefore reads only the first DVA
of a scrub read while a sorted scrub runs, since the other DVAs are
checked by their own queued reads, and reads them all only on retry.
Gang blocks are not queued: dsl_scan_enqueue() issues them at once and
whole, and their gang headers and gang members are read by gang
children of that one read. These inherit ZIO_FLAG_SCRUB and so take
the same shortcut, but nothing else ever reads their other DVAs. A
damaged copy of a gang header or gang member, other than the first, is
neither detected nor repaired by a scrub, unless the first copy is
damaged too and the retry reads them all. With the default
redundant_metadata=all every gang header has at least two copies, and
gang members have as many as the copies property asks for. A legacy
scrub (zfs_scan_legacy=1) reads and repairs every copy.
[11 lines not shown]
ZTS: test that a scrub repairs every copy of a gang block
With the default redundant_metadata=all, a gang header gets one more
copy than the block it describes, up to three, and each gang child
gets as many as the block. A scrub with the default sorted scan reads
only the first copy of each, so the other copies of a gang header or
of a gang child can be damaged without the scrub detecting or
repairing it. A legacy scrub (zfs_scan_legacy=1) reads and repairs
them.
Add a test that forces 128K blocks to gang on a file vdev, overwrites
the second copy of a gang header (copies=1) and of a gang child
(copies=2), scrubs, and checks that both copies were restored.
This fails now: the scrub repairs neither copy.
Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Signed-off-by: Tigerblue77 <37409593+tigerblue77 at users.noreply.github.com>
Closes #19399
EC2: Pass --vmdk to bsdec2-image-upload if needed
Starting with version 1.5.0, bsdec2-image-upload supports uploading
stream-optimized VMDK files. If we build images in that format, we
need to upload them appropriately.
MFC after: 2 weeks
Sponsored by: Amazon
(cherry picked from commit 65840afc88553f89c051b96b081061a532cb7df3)
__FreeBSD_version: Bump for mkimg -f vmdks
Also, adjust bootstrap tools code in Makefile.inc1 to reflect this; in
addition to rebuilding mkimg if it is out of date, we now need to build
libz, which was not previously needed by mkimg.
Reviewed by: kevans
MFC after: 2 weeks
Sponsored by: Amazon
Differential Revision: https://reviews.freebsd.org/D60153
X-Cherry-Pick: Logic in Makefile.inc1 was adjusted for new __FreeBSD_version
(cherry picked from commit a68ba2d2ce55f7c76174239c1f678379caec5348)
mkimg: Add image_buffer_region
This is like image_copyout_region, but copies into a buffer rather than
writing out to a file; it will be used by future support for compressed
images (and potentially other circumstances where image data must be
manipulated before being written out to disk).
Reviewed by: jrm
No objection from: Christos Komis (author)
MFC after: 2 weeks
Sponsored by: Google LLC (GSoC 2025)
Differential Revision: https://reviews.freebsd.org/D60149
(cherry picked from commit 84a3e29c72030dab16b4dc82d601d0af5da6a18c)
mkimg: Check for realloc failure
If realloc fails, clean up and return ENOMEM; don't just copy data
into NULL.
Reviewed by: emaste
Reported by: Claude Opus 5.5
MFC after: 2 weeks
Sponsored by: Amazon
Differential Revision: https://reviews.freebsd.org/D60147
(cherry picked from commit 1a0523197c5c16ce7bcb79d16c6bf8945258b428)
mkimg: Make vmdk's desc_fmt slightly more generic
This will allow it to be reused in upcoming work.
Suggested by: Claude Opus 5.5
MFC after: 2 weeks
Sponsored by: Amazon
Differential Revision: https://reviews.freebsd.org/D60150
(cherry picked from commit 498276b487c838afa2b3e4df322c43141788ba20)
mkimg: Avoid leaking a page of mmap
The image_file_map function adjusts the provided file offset to be
page-aligned, with a resulting increase in the size of the mapped
region; the increased size needs to be used when unmapping as well.
Reported by: Claude Opus 5.5
Fixes: baf4abfc39b2 ("Allow building mkimg as cross-tool")
MFC after: 2 weeks
Sponsored by: Amazon
Differential Revision: https://reviews.freebsd.org/D60148
(cherry picked from commit 434819b4fec5e508bdfe72f91e73402e9c2fca22)
mkimg: Add support for stream-optimized VMDK
FreeBSD VM/cloud images tend to be highly compressible: The generic VM
images compress roughly 3.5:1, and cloud images typically even more
since they have significant unused space in their virtual disks. This
generally doesn't matter for users who can download compressed release
images and extract them locally, but for EC2 in particular relying on
uncompressed image formats is painful: We now upload over 500 GB/week
to AWS.
This commit adds the "stream-optimized" version of the VMDK format,
which compresses each 64 kB "grain" individually (and omits grains
which are all zeroes). Compared to uncompressed formats, this can
produce much smaller images; experiments indicate that using this
format for EC2 image uploads will reduce the weekly traffic to under
100 GB/week.
Co-authored-by: Claude Opus 5.5
MFC after: 2 weeks
[4 lines not shown]
spl: avoid reclaim for speculative physical allocations
The constrained spl_kvmalloc() path allows direct reclaim while trying
to obtain physically contiguous memory, even though vmalloc can satisfy
the request with scattered pages. __GFP_NORETRY limits retries but does
not prevent that initial reclaim.
For multipage requests without __GFP_RETRY_MAYFAIL, clear direct reclaim
only from the physical attempt's flags. Keep the original flags for
fallback eligibility and vmalloc so a sleeping allocation can still
reclaim memory there. This follows the policy adopted by Linux 6.16
without changing the fallback needed by older supported kernels.
Retain the existing small-order retry policy and correct its obsolete
explanation of __GFP_RETRY_MAYFAIL.
Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Signed-off-by: Kamil Monicz <kamil at monicz.dev>
Closes #19406
