| Age | Commit message (Collapse) | Author |
|---|
|
Add a flexible memory region management system that provides:
- Memory region type classification (System, Graphics, IO, Binary)
- Memory region permission management (executable, writable)
- Binary base address randomization for ASLR
- Dynamic memory mapping capabilities
Credit: boss.smc@citron-emu.org
Signed-off-by: Zephyron <zephyron@citron-emu.org>
|
|
Add more detailed debug logging and validation to the InvalidateNCE function:
- Add entry debug log showing NCE invalidation request details
- Add upfront validation of memory region before proceeding
- Add debug logs for rasterizer and separate heap handling cases
- Add warning logs for invalid address ranges and failed invalidations
- Improve error message formatting and clarity
- Group related operations with descriptive comments
These changes make it easier to debug NCE invalidation issues by providing
more visibility into the validation steps and failure cases.
|
|
- Update vcpkg baseline to a42af01b72c28a8e1d7b48107b33e4f286a55ef6
- Add SPIRV-Tools and SPIRV-Headers as submodules
- Update Vulkan-related submodules to latest stable versions
- Improve memory access error handling:
- Add specific handling for null pointer accesses in ARM32 emulation
- Return 0 for null pointer reads instead of undefined behavior
- Silently ignore writes to null pointers
- Add more detailed error messages distinguishing between null pointer
access and other unmapped memory errors
- Treat addresses below 0x1000 as potential null pointer accesses
These changes should provide more graceful handling of null pointer
accesses and improve stability when running games that attempt invalid
memory operations.
|
|
|
|
Allows the use of the macro in constexpr-contexts.
Also avoids some potential problems when nesting braces inside it.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Revert PR #11806 and do a proper fix to the memory handling.
|
|
|
|
Co-authored-by: Kelebek1 <eeeedddccc@hotmail.co.uk>
|
|
memory: check page against address space size
|
|
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.
|
|
|
|
|
|
with the host GPU
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This reverts commit af5ecb0b15d4449f58434e70eed835cf71fc5527.
|
|
|
|
|
|
memory: correct semantics of data cache management operations
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Some header files, specifically for OSX and Musl libc define PAGE_SIZE to be a number
This is great except in yuzu we're using PAGE_SIZE as a variable
Specific example
`static constexpr u64 PAGE_SIZE = u64(1) << PAGE_BITS;`
PAGE_SIZE PAGE_BITS PAGE_MASK are all similar variables.
Simply deleted the underscores, and then added YUZU_ prefix
Might be worth noting that there are multiple uses in different classes/namespaces
This list may not be exhaustive
Core::Memory 12 bits (4096)
QueryCacheBase 12 bits
ShaderCache 14 bits (16384)
TextureCache 20 bits (1048576, or 1MB)
Fixes #8779
|
|
[REUSE] is a specification that aims at making file copyright
information consistent, so that it can be both human and machine
readable. It basically requires that all files have a header containing
copyright and licensing information. When this isn't possible, like
when dealing with binary assets, generated files or embedded third-party
dependencies, it is permitted to insert copyright information in the
`.reuse/dep5` file.
Oh, and it also requires that all the licenses used in the project are
present in the `LICENSES` folder, that's why the diff is so huge.
This can be done automatically with `reuse download --all`.
The `reuse` tool also contains a handy subcommand that analyzes the
project and tells whether or not the project is (still) compliant,
`reuse lint`.
Following REUSE has a few advantages over the current approach:
- Copyright information is easy to access for users / downstream
- Files like `dist/license.md` do not need to exist anymore, as
`.reuse/dep5` is used instead
- `reuse lint` makes it easy to ensure that copyright information of
files like binary assets / images is always accurate and up to date
To add copyright information of files that didn't have it I looked up
who committed what and when, for each file. As yuzu contributors do not
have to sign a CLA or similar I couldn't assume that copyright ownership
was of the "yuzu Emulator Project", so I used the name and/or email of
the commit author instead.
[REUSE]: https://reuse.software
Follow-up to 01cf05bc75b1e47beb08937439f3ed9339e7b254
|
|
|
|
|
|
|
|
CPU Cached memory."
|
