eglantine-cirakg/src/core/arm/arm_interface.cpp, branch nx2

[common/logging] Simplify logging logic and fix issues when logging before system is created (#3688)

2026-03-12T17:29:15+00:00

- our logging code was bigger than spdlog itself, why???? just keep it simple - fix issues when logging before logging system is even started - removes the "initialized logging twice" issue - removes uneeded indirection in file logging - uses direct formatting instead of jumping hoopla-around the fmt::format() ressult - code duplication and dead code removal as usual I did explore dup2() but I think it's not worth the hassle I did try `fwopen()` but it's better if things are just kept as-is. there is a lot of noise because I removed a bunch of redundant files on logging and just put everything in one file now normally this wouldn't be a good idea, however consider: the complexity of logging; it's less than 500 lines... does it really need a whole subsystem?!?!?! ITS JUST LOGGING Signed-off-by: lizzie Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3688 Reviewed-by: crueter Reviewed-by: DraVee Reviewed-by: CamilleLaVey Co-authored-by: lizzie Co-committed-by: lizzie

[core/arm] more verbose backtrace showing ALL of the thread's context state (#2924)

2025-11-03T20:08:02+00:00

Should make backtraces infinitely better :) Signed-off-by: lizzie Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/2924 Reviewed-by: Caio Oliveira Reviewed-by: MaranBr Co-authored-by: lizzie Co-committed-by: lizzie

[arm] allow duplicate addresses on backtrace (#251)

2025-08-15T21:20:08+00:00

As a reminder, never remove duplicate entries from a back-trace, ever. Signed-off-by: lizzie Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/251 Reviewed-by: crueter Co-authored-by: lizzie Co-committed-by: lizzie

arm: Skip duplicate consecutive addresses in backtrace output

2025-04-19T20:56:48+00:00

ref: https://git.citron-emu.org/Citron/Citron/commit/aa56430f2a3179068f77b865d4fd0179aa5cc4c4

kernel: instantiate memory separately for each guest process

2023-12-23T02:52:49+00:00

core: refactor emulated cpu core activation

2023-12-04T15:37:16+00:00

arm: Print backtrace on data abort

2023-11-25T05:47:36+00:00

core: check for thread dpc before eret

2023-11-13T16:28:23+00:00

kernel: update KProcess

2023-10-22T00:03:41+00:00

Fixes and workarounds to make UBSan happier on macOS

2023-07-15T19:00:28+00:00

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.