Core::GetState reads from four different pieces of state: s_is_stopping,
s_hardware_initialized, s_is_booting, and CPUManager::IsStepping.
I'm keeping that last one as is for now because there's code in Dolphin
that sets it directly, but we can unify the other three to make things
easier to reason about.
This commit also gets rid of s_is_started. This was previously used in
Core::IsRunningAndStarted to ensure true wouldn't be returned until the
CPU thread was started, but it wasn't used in Core::GetState, so
Core::GetState would happily return State::Running after we had
initialized the hardware but before we had initialized the CPU thread.
As far as I know, there are no callers that have any real need to know
whether the boot process is currently initializing the hardware or the
CPU thread. Perhaps once upon a time there was a desire to make the
apploader debuggable, but a long time has passed without anyone stepping
up to implement it, and the way CBoot::RunApploader is implemented makes
it rather difficult. So this commit makes all the functions in Core.cpp
consider the core to still be starting until the CPU thread is started.
This lets us reduce the number of USE_RETRO_ACHIEVEMENTS ifdefs in the
code base, reducing visual clutter. In particular, needing an ifdef for
each call to IsHardcodeModeActive was annoying to me. This also reduces
the risk that someone writes code that accidentally fails to compile
with USE_RETRO_ACHIEVEMENTS disabled.
We could cut down on ifdefs even further by making HardcodeWarningWidget
always exist, but that would result in non-trivial code ending up in the
binary even with USE_RETRO_ACHIEVEMENTS disabled, so I'm leaving it out
of this PR. It's not a lot of code though, so I might end up revisiting
it at some point.
The client can handle media changes natively so disabling can take place internally. This code uses the same external calls to load data, but will call either BeginLoad or BeginChangeMedia based on whether any media is already loaded.
Due to the client's handling of media changes (it simply disables hardcore if an unknown media is detected) the existing functionality for "disabling" the achievements is no longer necessary and can be deleted.
Also make the `Decrypt` method private.
As far as I can tell, the only motivation for exposing the `SetBytes`
and `Reset` methods is to allow `CBoot::SetupWiiMemory` to use the same
`SettingsHandler` instance to read settings data and then write it back.
It seems cleaner to just use two separate instances, and require a given
`SettingsHandler` instance to be used for either writing data to a
buffer or reading data from a buffer, but not both.
A natural next step is to split the `SettingsHandler` class into two
classes, one for writing data and one for reading data. I've deferred
that change for a future PR.
Typically when someone uses GetPointer, it's because they want to read
from a range of memory. GetPointer is unsafe to use for this. While it
does check that the passed-in address is valid, it doesn't know the size
of the range that will be accessed, so it can't check that the end
address is valid. The safer alternative GetPointerForRange should be
used instead.
Note that there is still the problem of many callers not checking for
nullptr.
This is the first part of a series of changes that will remove the usage
of GetPointer in different parts of the code base. This commit gets rid
of every GetPointer call from our IOS code except for a particularly
tricky one in BluetoothEmuDevice.
There were three distinct mechanisms for signaling symbol changes in DolphinQt: `Host::NotifyMapLoaded`, `MenuBar::NotifySymbolsUpdated`, and `CodeViewWidget::SymbolsChanged`. The behavior of these signals has been consolidated into the new `Host::PPCSymbolsUpdated` signal, which can be emitted from anywhere in DolphinQt to properly update symbols everywhere in DolphinQt.
Makes these implementations more thread-safe by design. These likely
won't be run on any other thread, but we may as well just use the
re-entrant variant if it's available.
Keep a shared_ptr to NetKDTimeDevice inside NetKDRequestDevice.
This allows the KDDownload task to finish its work without potentially
trying to dereference nullptr, which can potentially come from either
GetIOS() or GetDeviceByName() if EmulationKernel's destructor has
started running.
Explicitly shut down work queues in NetKDRequestDevice's destructor to
prevent their threads from accessing members after they've been freed.
This crash would occur sporadically if NetKDRequestDevice's periodic
download or mail checks happened to overlap with emulation shutdown in
the wrong way.
An example sequence of events that could cause the crash:
* m_scheduler_timer_thread queues a periodic Download event in
m_scheduler_work_queue, then waits for m_shutdown_event.
* A request to stop emulation results in s_ios being reset by the CPU
thread. This triggers NetKDRequestDevice's destructor which sets
m_shutdown_event and joins m_scheduler_timer_thread.
* m_scheduler_timer_thread wakes from m_shutdown_event and returns from
its thread function, ending the thread.
* The CPU thread resumes execution at the end of NetKDRequestDevice's
destructor and begins destroying NetKDRequestDevice's members in
reverse declaration order.
* m_http is declared after m_scheduler_work_queue and is therefore
destroyed earlier.
* m_scheduler_work_queue's destructor calls its Shutdown function, which
by default finishes the work items in the queue.
* The queued Download event calls KDDownload which calls m_http.Get()
which calls Fetch() which passes garbage data from the freed m_curl
into curl_easy_setopt().
* Curl promptly crashes.
Shutting down the work queues manually in the destructor prevents the
above because m_http and the other members don't get freed until after
the queue threads finish.
Eliminates a deprecation warnings on macOS. While we're in the
same area, we can remove the call to GetPointer() and instead
use CopyToEmu() to copy the string data back to the emulated memory.
