[DebugMetadata][DwarfDebug][CodeView] Support function-local static variables in lexical block scopes (6/7) (#187927)
RFC
https://discourse.llvm.org/t/rfc-dwarfdebug-fix-and-improve-handling-imported-entities-types-and-static-local-in-subprogram-and-lexical-block-scopes/68544
Similar to imported declarations and types, the patch tracks
function-local static variables (globals in terms of LLVM IR) in
DISubprogram's 'retainedNodes'. DwarfDebug is adjusted in accordance
with the aforementioned metadata change and provided a support of static
locals scoped by a lexical block. CodeViewDebug is modified to collect
global variables from DISubprogram's 'retainedNodes' too.
The patch assumes that DICompileUnit's 'globals' no longer tracks static
locals and DwarfDebug would assert if any locally-scoped variables get
placed there.
This change has already been reviewed in
https://reviews.llvm.org/D144008, but I’m opening a new PR because it
has been a while since it was approved. Additional logic was added to
[6 lines not shown]
x86/local_apic.c: Fiddle with thermal LVT slot only if supported
The thermal LVT slot does not necessarily exist.
According to Intel's Software Developers Manual, for Intel processors
supporting 64-bit operation (amd64), probably even the earliest ones
should have a local APIC with such a slot (the slot was introduced with
Pentium 4 and Xeon processors according to the manual, and the 64-bit
implementation in some later versions of them). AMD's Architecture
Programmer's Manual also seems to imply that all AMD processors
supporting amd64 should have the slot too. So this change may not be
needed when i386's code is dropped, but it does not hurt to have it, and
it might ease possible MFCs.
Change the signature of lapic_enable_thermal() so that it can report
failure (if there is no local APIC or if there is no thermal LVT slot).
Reviewed by: bnovkov, kib
MFC after: 2 weeks
[2 lines not shown]
x86/local_apic.c: Factor out version read and max LVT slot computation
This makes the code slightly more compact and easier to read.
No functional change intended.
Reviewed by: bnovkov
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D58110
linux: Add TCP_INFO support
Implement the getsockopt for TCP_INFO by mapping FreeBSD's version to
what Linux expects.
(cherry picked from commit 925ca9b8355d10a0dc85175dc865095c9b3370c4)
rk_gpio: implement PIC masking methods and mask unhandled IRQs
The Rockchip GPIO controller implements PIC operations for the INTRNG
framework but is missing four masking methods that INTRNG calls during
the filter/ithread handoff: pic_disable_intr, pic_enable_intr,
pic_pre_ithread, pic_post_ithread.
Without them, level-sensitive interrupt sources connected to a
Rockchip GPIO pin re-fire continuously while their ithread runs. On
a RockPro64 with a FUSB302B Type-C controller (i2c) attached to
gpio1 INT_N, the system enters a ~210 kHz interrupt storm the moment
the fusb302 driver attaches and INT_N goes low.
Two complementary changes:
1. Add the four pic_disable_intr/pic_enable_intr/pic_pre_ithread/
pic_post_ithread method bodies. Each toggles the pin's
RK_GPIO_INTMASK bit so the source is masked during the in-flight
ithread window and unmasked on return, honouring the generic
[19 lines not shown]
crashinfo: Create core.txt.last symlink
When saving a coredump, savecore(8) maintains .last symlinks for the
info and vmcore artifacts, but not for the crashinfo text report.
Make crashinfo(8) create the link, pointing at the current
core.txt.<bounds> file.
This makes /var/crash/core.txt.last track the same core dump as
info.last and vmcore.last.
[mhorne: I tweaked the submission, such that the link will be created as
soon as the core.txt.X file is generated; not only after a successful
report has been written.]
Signed-off-by: Ricardo Branco <rbranco at suse.de>
Reviewed by: mhorne
MFC after: 1 week
Pull Request: https://github.com/freebsd/freebsd-src/pull/2199
[2 lines not shown]
hwpmc_amd: Avoid using PMCs if in use by firmware
Some firmwares use the PMCs to monitor OS performance. We can't be
certain that the BIOS would detect any change to the counters if we
reprogram them. In cases where the firmware is using the PMCs to
control power management this could have dangerous side effects or
unexpected performance effects.
During initialization, detect if any of the counters are enabled and
fail if so.
Reported by: Sandipan Das
Reviewed by: mhorne
MFC after: 1 week
Sponsored by: Netflix
Pull Request: https://github.com/freebsd/freebsd-src/pull/2277
(cherry picked from commit cf469ab83012ee47d06bc89874b6c109f49446e0)
hwpmc: Disable AMD PMCs if in an unsupported VM
AMD does not have a CPUID bit to indicate the lack of K8 PMCs. If all
other PMC features are not present we should test an event selector to
see if it stores and returns a value. If the VM is implemented
correctly, this should result in a #GP on the initial wrmsr_safe. Bhyve
and a few other VMs ignore writes, so I got one step further and test
that it retains the OS and USR bits.
Tested on Zen 5 native and a Zen 5 Bhyve virtual machine. This code
should not run on any recent hardware, except in a VM, as it checks that
the core counter extension is missing.
PR: 268943
Reported by: Sandipan Das, John F. Carr <jfc at mit.edu>
Reviewed by: mhorne, imp
Sponsored by: Netflix
MFC after: 1 week
Pull Request: https://github.com/freebsd/freebsd-src/pull/2272/changes
[2 lines not shown]
hwpmc_amd: Add support for additional counters.
Rather than provide a static table of counters, this change computes the
number of counters that are available by checking several CPUID leafs
and falling back to defaults on older processors. The limits are set to
support the maximum number of counters of each type.
Sponsored by: Netflix
Reviewed by: imp, mhorne
Pull Request: https://github.com/freebsd/freebsd-src/pull/1983
(cherry picked from commit 37bba2ad92d8fa81d70f7a8243b2f42981f44454)
hwpmc_amd: fix amd_get_msr() MSR offset for newer counter bases
The previous code subtracted AMD_PMC_PERFCTR_0 (0xC0010004) from all
perfctr MSR addresses to compute a relative offset. This is incorrect
for counters using AMD_PMC_CORE_BASE (0xC0010200), AMD_PMC_L3_BASE
(0xC0010230), and AMD_PMC_DF_BASE (0xC0010240), producing wrong offsets.
Fix by promoting amd_core_npmcs, amd_l3_npmcs, and amd_df_npmcs to
static module-level variables and computing the correct flat RDPMC
index per AMD BKDG 24594 page 440:
ECX 0-5: Core counters 0-5
ECX 6-9: DF counters 0-3
ECX 10-15: L3 Cache counters 0-5
ECX 16-27: DF counters 4-15
ECX > 27: Reserved, returns EINVAL
Reviewed by: Ali Mashtizadeh <ali at mashtizadeh.com>, mhorne
Sponsored by: NLINK (https://nlink.com.br), Recife, Brazil
[4 lines not shown]
hwpmc: Fix PMC flags for AMD Zen cores
The PMC flags available for DF and L3 counters were not all implemented.
More importantly, the field encodings for the L3 counters changed in an
incompatible way between Family 17h and Family 19h. Similarly, the
field encodings for the DF coutners changed between Family 19h and 1Ah.
I also added the precise retire flag for the 3rd core counter.
Lastly, I added a warning in the jevent parser because ignoring the
unknown fields results in counters incorrectly programmed. We should
not just ignore that.
Sponsored by: Netflix
Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/2040
(cherry picked from commit 00c0a1f0bf6c07e63384a389060dfc10924c0ed6)
build: Retire LLVM_COV src.conf knob
I introduced it in commit 1b49115a40ad ("Promote llvm-cov to a
standalone option"). llvm-cov was previously enabled as part of the
CLANG_EXTRAS option. I made it a standalone, default-enabled option for
parity with the tools provided by the GCC-based toolchain.
We no longer provide an in-tree GCC toolchain. Now, just build llvm-cov
along with Clang to simplify build infrastructure.
Reviewed by: dim
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D58155
x86: Save and restore all supported extended CPU state on signals.
While here, disable Intel AMX, whose state size (>>8 KiB) exceeds
MINSIGSTKSZ (8 KiB), until we are ready to safely update the ABI for
sigaltstack(2). This isn't a regression: we've never had a release
with Intel AMX support.
Previously, on signal delivery, we would only save and restore at
most what FXSAVE does, which is the x87 and SSE registers that always
exist on amd64.
To save and restore the upper halves of the YMM or ZMM registers
(AVX/AVX2/AVX512), or the AVX512 registers ZMM16..ZMM31, or the
enormous AMX state, we need to do more. And we need to do that even if
the signal handler doesn't use AVX instructions, because an SSE
instruction modifying xmmN (e.g., in a vectorized memcpy) will, as a
side effect, zero the high half of ymmN.
Fortunately, the x86 architecture has an extensible mechanism for
[47 lines not shown]
[lldb][Windows] Support modules with long paths (#206099)
`PlatformWindows::DoLoadImage` injected a 261-byte buffer for the loaded
module path. Longer paths would be truncated and fail to load. This
patch adds a growing buffer (up to the NT limit) which is used only when
`GetModuleFileNameA` reports truncation, re-querying without taking an
extra reference on the module.
This patch also adds 3 tests for lldb, lldb-driver and the SBAPI. They
are really regression tests which break if long path support regresses.
Requires:
- https://github.com/llvm/llvm-project/pull/206046
- https://github.com/llvm/llvm-project/pull/206060
[AArch64][SVE] Support lowering masked stores of <4 x bf16> and <8 x bf16>
Add support for lowering masked stores of <4 x bf16> and <8 x bf16> when
target features contain "+sve".
Fixes: #201149
beinstall: Avoid chrooting into new world
The new world may use system calls that are not in the currently-running
kernel, so we cannot chroot into the new environment to run `make
installworld`, `etcupdate`, etc. Partially revert commit 16702050ac95
("beinstall: perform pre-installworld steps") and switch back to using
DESTDIR for installworld and so on.
Reported by: olivier
Reviewed by: olivier
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D50682
AMDGPU/GlobalISel: Handle G_BITCAST for 16 bit extendedLLTs
Handle bitcast between i16 and f16/bf16.
For true16 this was already legal, make it legal in regbanklegalize as well.
For non-true16 custom lower it to G_ANYEXT to i32 and G_TRUNC to dst.
The "i32 G_ANYEXT f16/bf16" and "f16/bf16 G_TRUNC i32" are already legal,
for example these are generated by common CallLowering argument lowering.
AMDGPU/GlobalISel: Switch RegBankLegalize lowering to extended LLTs
Stop using LLT::scalar for lowering in AMDGPURegBankLegalizeHelper
Affects integer lowering code for RegBankLLTMappingApplyID and
custom cpp for LoweringMethodID.
[SPIR-V] Fix crash on switch with odd-width condition type (#208026)
getPreferredSwitchConditionType called getSimpleVT unconditionally,
which asserts on extended EVTs like i31
Return i1 for non-simple types to keep CodeGenPrepare from widening the
condition
[X86] EltsFromConsecutiveLoads - handle trunc(wideload()) patterns (#199371)
The existing path emits N x vpinsrb for buildvecs whose elements are
loads at a regular byte stride larger than the element size:
```asm
movzbl 216(%rsp), %eax
vmovd %eax, %xmm0
vpinsrb $1, 224(%rsp), %xmm0, %xmm0
vpinsrb $2, 232(%rsp), %xmm0, %xmm0
...
vpinsrb $15, 336(%rsp), %xmm0, %xmm0
```
This patch adds a strided-load path to EltsFromConsecutiveLoads that
folds these into wide load(s) + vector truncation:
```asm
vmovdqu64 216(%rsp), %zmm0
[29 lines not shown]
[mlir][vector] Fix crash on untraceable masks in getCompressedMaskOp (#207299)
The loop tracing a mask back to its creation op assumed the chain always
ends at a create_mask/constant_mask/arith.constant, a block-argument
mask made it fall through to isa<> on a null op (segfault), and any
other unhandled defining op spun it forever.
Fixes #206928
Claude Fable 5 did assist with this.
