Ignore `!guid` metadata when merging globals or constants (#200323)
Follow up from PR #184065. Since globals or constants would now have
their GUID pre-calculated and affixed with metadata, we need to tolerate
its presence when merging. To that effect, we rename (and change
accordingly) `GlobalObject::hasMetadataOtherThanDebugLoc` to
`...AndGuid`.
In the case of Constants, they are merged into one of them, which then
keeps its guid, while the rest are erased. In the case of
GlobalVariables, a new one is created, and we will give it its own guid.
Add NVPTX DW_AT_LLVM_language_dialect emission. (#200003)
This PR makes use of the recently introduced DW_AT_LLVM_language_dialect
attribute. Currently, no other targets emit this compile unit DWARF
attribute ; however, this PR changes that. NVPTX can optionally emit a
dialect based on the type of input being compiled (e.g., from a Tile
frontend or traditional CUDA (SIMT) frontend).
- DwarfDebug: add finishTargetUnitAttributes virtual hook so backends
can finalize per-CU attributes.
- NVPTX: override the hook to emit DW_AT_LLVM_language_dialect
(DW_FORM_data1) for the simt and tile dialects, suppressing emission and
warning (per-CU deduplicated) for unknown values.
(Co-developed via LLM)
MAC/do: Add consistency tests
Test that:
1. Concurrent changes to different parameters on the same jail are
independent/atomic.
2. Inheritance works.
3. Relaxing only parent jail rules does not leak to a subjail thanks to
sequential consistency.
4. Sysctl knobs and jail parameters stay consistent.
Some of these tests may be extended in the future with several layers of
jails (there is only a single subjail currently).
Reviewed by: bapt
MFC after: 1 month
Sponsored by: The FreeBSD Foundation
Pull Request: https://ron-dev.freebsd.org/FreeBSD/src/pulls/38
MAC/do: Tests: Add support for exec paths, jail parameters, subjails
And also allow configuration of the mdo(1) executable path.
This commit only contains new or modified infrastructure. No functional
change intended at this point.
Reviewed by: bapt
MFC after: 1 month
Sponsored by: The FreeBSD Foundation
Pull Request: https://ron-dev.freebsd.org/FreeBSD/src/pulls/38
MAC/do: Tests: Quote the source directory
In a standard test suite installation, this is not necessary, but be
bullet-proof to custom ones, however improbable.
Reviewed by: bapt
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
Pull Request: https://ron-dev.freebsd.org/FreeBSD/src/pulls/38
MAC/do: Tests: Fix copyrights
No comma needed after a single year. Add SPDX.
Reviewed by: bapt
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
Pull Request: https://ron-dev.freebsd.org/FreeBSD/src/pulls/38
MAC/do: Tests: Remove shebang lines
They are automatically added by <bsd.test.mk>.
Reviewed by: bapt
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
Pull Request: https://ron-dev.freebsd.org/FreeBSD/src/pulls/38
mac_do.4: Document executable paths, default jail values and consistency
While here, fix the bug of mentioning 'enable' as a possible value for
the 'mac.do' jail parameter whereas it is 'new' instead.
Reviewed by: bapt
MFC after: 1 month
Sponsored by: The FreeBSD Foundation
Pull Request: https://ron-dev.freebsd.org/FreeBSD/src/pulls/38
[InstCombine] Replace undef with poison in a test (#199757)
This is intended as part of the effort to deprecate undef. The
additional wrap-flags are due to the fact that the add can no longer
overflow with poison, but could overflow with undef.
Alive2 proof: https://alive2.llvm.org/ce/z/qiRYcQ
MAC/do: Update copyright
Update years for the Foundation.
While here, remove the initial '/*-' which has been useless for a long
time.
While here, add a missing space on bapt@'s copyright line (approved by
him).
Reviewed by: bapt
MFC after: 1 month
Sponsored by: The FreeBSD Foundation
Pull Request: https://ron-dev.freebsd.org/FreeBSD/src/pulls/38
[WebAssembly] Avoid crash in LateEHPrepare with empty cleanup pads (#200322)
WebAssemblyLateEHPrepare::addCatchRefsAndThrowRefs was using
Catch->getIterator()->getNextNode() to find the insertion position
after the CATCH (or CATCH_ALL) instruction in an EH pad.
If the CATCH/CATCH_ALL instruction is the last instruction in the basic
block, getNextNode() returns nullptr, which causees a crash when passed
to BuildMI. This patch fixes it by using std::next(Catch->getIterator())
which returns MBB.end() if the catch is the last instruction, and the
overload of BuildMI that takes an iterator correctly handles BB.end().
Fixes #197077
Assisted-By: Gemini
MAC/do: Do not skip blanks when parsing executable paths
The kind of tolerance we apply to parsing rules, whose format we have
defined, cannot be applied to paths since blank characters are allowed
there.
There is still the limitation that no escape character is currently
supported, and so it is not possible to configure a path having a ':'
character.
Reviewed by: bapt
Fixes: 9818224174c4 ("MAC/do: Executable paths feature (GSoC 2025's final state)")
MFC after: 1 month
Sponsored by: The FreeBSD Foundation
Pull Request: https://ron-dev.freebsd.org/FreeBSD/src/pulls/38
MAC/do: Serialize installing/modifying some jail's configuration
See the immediately preceding commit for explanations on what this is
fixing.
When setting 'mac.do' to 'inherit' on a jail with 'mac.do.rules' and
'mac.do.exec_paths' also specified in the same call, ensure that the
check that these passed parameters are the same as those to be inherited
is atomic with respect to enabling the inheritance (i.e., removing the
jail's 'struct conf' object). (See previous commit "MAC/do: Fix the
recent logic to set jail parameters, make it more tolerant" as for why
this check exists.)
Because we currently only modify a single configuration object per
transaction, we introduce the parse_and_commit_conf() wrapper around
parse_and_set_conf() to remove duplicated code that would ensue from
calling the latter directly, namely, releasing the 'mac_do_rwl' lock and
freeing the old configuration object (if any).
[9 lines not shown]
MAC/do: Support for atomically modifying configurations
As mentioned in previous commits "MAC/do: parse_and_set_conf(): Require
the model configuration" and "MAC/do: Sequential consistency for
configuration retrieval", the introduction of the "executable path"
feature, more fundamentally, the fact that there is now more than one
per-jail parameter and that parameters can be independently modified or
copied, causes an atomicity problem in case of concurrent accesses to of
a jail's applicable configuration.
Partially modifying a configuration is indeed akin to
a read-modify-write operation, where the read is either to the current
or an inherited configuration. More precisely, once pointed to by
a jail, a configuration object is immutable, and changing the jail's
configuration means making the jail point to another configuration
object. To change a jail's configuration, a new configuration object is
thus built, and if only some parameters have been explicitly specified,
those that have not been are set by copying the corresponding values
from an existing configuration object (in case of partial modification
[34 lines not shown]
security/libgcrypt: drop our custom aarch64 feature detection
Hardware crypto features are found with elf_aux_info() out of the box.
Confirmed by timings from the test suite.
ok ajacoutot@
MAC/do: Sequential consistency for configuration retrieval
Since the inception of mac_do(4), find_conf(), used to retrieve the
applicable configuration, has been weakly consistent with respect to
concurrent modifications to configuration inheritance that influence its
result (and it has been sequentially consistent with respect to other
configuration modifications, which the initial executable paths feature
and introduction of implicit parameters broke and which will be fixed in
a subsequent commit).
Indeed, find_conf() climbs the jail tree to find an applicable
configuration, which is not an atomic operation. It examines the
current jail's configuration pointer for each browsed jail, which does
not prevent concurrent modifications of the configuration pointer for
jails below or above it. Modifications above the current jail are not
a problem, since if climbing needs to continue (i.e., the current jail
inherits), these modifications will be seen if performed before that
check (and may or may not be seen if performed after that check).
However, modifications below the current jail impair sequential
[48 lines not shown]
MAC/do: Comment to explain the main invariant for configurations
Once visible, configuration structures must *never* change.
Spell that out in a comment to help future readers/contributors
understand the design.
Reviewed by: bapt
MFC after: 1 month
Sponsored by: The FreeBSD Foundation
Pull Request: https://ron-dev.freebsd.org/FreeBSD/src/pulls/38
MAC/do: Allocate only one default configuration
When mac_do(4) is loaded, all jails get the same default configuration
(disabled, with only one allowed executable path: '/usr/bin/mdo').
Share it between all jails instead of creating a separate copy for each.
Reviewed by: bapt
Fixes: 9818224174c4 ("MAC/do: Executable paths feature (GSoC 2025's final state)")
MFC after: 1 month
Sponsored by: The FreeBSD Foundation
Pull Request: https://ron-dev.freebsd.org/FreeBSD/src/pulls/38
Revert "[DenseMap] Replace tombstone deletion with TAOCP 6.4 Algorithm R" (#200421)
Reverts llvm/llvm-project#199615.
That change causes nondeterministic failed assertions, see the linked PR
for examples.
MAC/do: Visually separate some file sections
With additional empty lines.
No functional change (intended).
Reviewed by: bapt
MFC after: 1 month
Sponsored by: The FreeBSD Foundation
Pull Request: https://ron-dev.freebsd.org/FreeBSD/src/pulls/38
MAC/do: Fix reporting of "mac.do" post-"executable paths"
In mac_do_jail_get(), computation of 'jsys' had not been updated to take
into account executable paths.
Reviewed by: bapt
Fixes: 9818224174c4 ("MAC/do: Executable paths feature (GSoC 2025's final state)")
MFC after: 1 month
Sponsored by: The FreeBSD Foundation
Pull Request: https://ron-dev.freebsd.org/FreeBSD/src/pulls/38
MAC/do: Configuration: Fix default values: Remove jail creation method
mac_do_jail_create() would create a default configuration on the
just-created jail, erroneously causing mac_do_jail_set() to then
retrieve it and use it as a model when determining the default values
for not-specified parameters, instead of using the configuration
applicable to the parent jail.
Setting a default configuration in mac_do_jail_create() had been done as
a kind of defensive measure to prevent a created jail not to have
a configuration (effectively making it inherit from an ancestor jail,
which is a security hazard except if explicitly requested). However,
this measure was never really effective (osd_jail_call(PR_METHOD_CREATE)
in kern_jail_set() calls the PR_PETHOD_CREATE methods in an unspecified
order, and stops at the first error), so we are forced to rely in any
case on the fact that an error in a PR_METHOD_CREATE or PR_METHOD_SET
method leads to stopping the jail creation process (which is the case
today; see kern_jail_set()).
[5 lines not shown]
