diff options
author | comex <comexk@gmail.com> | 2023-07-01 15:00:39 -0700 |
---|---|---|
committer | comex <comexk@gmail.com> | 2023-07-15 12:00:28 -0700 |
commit | d7c532d8894ce806c9af13b8dd3eec975642b348 (patch) | |
tree | 1353e6d1776384575019db28987e23237552a9de /src/core/arm | |
parent | 04868ab9da2049429808a265dc50696f6300b2b4 (diff) |
Fixes and workarounds to make UBSan happier on macOS
There are still some other issues not addressed here, but it's a start.
Workarounds for false-positive reports:
- `RasterizerAccelerated`: Put a gigantic array behind a `unique_ptr`,
because UBSan has a [hardcoded limit](https://stackoverflow.com/questions/64531383/c-runtime-error-using-fsanitize-undefined-object-has-a-possibly-invalid-vp)
of how big it thinks objects can be, specifically when dealing with
offset-to-top values used with multiple inheritance. Hopefully this
doesn't have a performance impact.
- `QueryCacheBase::QueryCacheBase`: Avoid an operation that UBSan thinks
is UB even though it at least arguably isn't. See the link in the
comment for more information.
Fixes for correct reports:
- `PageTable`, `Memory`: Use `uintptr_t` values instead of pointers to
avoid UB from pointer overflow (when pointer arithmetic wraps around
the address space).
- `KScheduler::Reload`: `thread->GetOwnerProcess()` can be `nullptr`;
avoid calling methods on it in this case. (The existing code returns
a garbage reference to a field, which is then passed into
`LoadWatchpointArray`, and apparently it's never used, so it's
harmless in practice but still triggers UBSan.)
- `KAutoObject::Close`: This function calls `this->Destroy()`, which
overwrites the beginning of the object with junk (specifically a free
list pointer). Then it calls `this->UnregisterWithKernel()`. UBSan
complains about a type mismatch because the vtable has been
overwritten, and I believe this is indeed UB. `UnregisterWithKernel`
also loads `m_kernel` from the 'freed' object, which seems to be
technically safe (the overwriting doesn't extend as far as that
field), but seems dubious. Switch to a `static` method and load
`m_kernel` in advance.
Diffstat (limited to 'src/core/arm')
-rw-r--r-- | src/core/arm/arm_interface.cpp | 4 | ||||
-rw-r--r-- | src/core/arm/arm_interface.h | 2 |
2 files changed, 3 insertions, 3 deletions
diff --git a/src/core/arm/arm_interface.cpp b/src/core/arm/arm_interface.cpp index aa0eb9791..0c012f094 100644 --- a/src/core/arm/arm_interface.cpp +++ b/src/core/arm/arm_interface.cpp @@ -217,8 +217,8 @@ void ARM_Interface::Run() { } } -void ARM_Interface::LoadWatchpointArray(const WatchpointArray& wp) { - watchpoints = ℘ +void ARM_Interface::LoadWatchpointArray(const WatchpointArray* wp) { + watchpoints = wp; } const Kernel::DebugWatchpoint* ARM_Interface::MatchingWatchpoint( diff --git a/src/core/arm/arm_interface.h b/src/core/arm/arm_interface.h index d5f2fa09a..3d866ff6f 100644 --- a/src/core/arm/arm_interface.h +++ b/src/core/arm/arm_interface.h @@ -186,7 +186,7 @@ public: virtual void SaveContext(ThreadContext64& ctx) const = 0; virtual void LoadContext(const ThreadContext32& ctx) = 0; virtual void LoadContext(const ThreadContext64& ctx) = 0; - void LoadWatchpointArray(const WatchpointArray& wp); + void LoadWatchpointArray(const WatchpointArray* wp); /// Clears the exclusive monitor's state. virtual void ClearExclusiveState() = 0; |