Both member functions assume the passed in target process will not be
null. Instead of making this assumption implicit, we can change the
functions to be references and enforce this at the type-system level.
* Kernel: reimplement memory management on physical FCRAM
* Kernel/Process: Unmap does not care the source memory permission
What game usually does is after mapping the memory, they reprotect the source memory as no permission to avoid modification there
* Kernel/SharedMemory: zero initialize new-allocated memory
* Process/Thread: zero new TLS entry
* Kernel: fix a bug where code segments memory usage are accumulated twice
It is added to both misc and heap (done inside HeapAlloc), which results a doubled number reported by svcGetProcessInfo. While we are on it, we just merge the three number misc, heap and linear heap usage together, as there is no where they are distinguished.
Question: is TLS page also added to this number?
* Kernel/SharedMemory: add more object info on mapping error
* Process: lower log level; SharedMemory: store phys offset
* VMManager: add helper function to retrieve backing block list for a range
Two functional change:
QueryProcessMemory uses the process passed from handle instead current_process
Thread::Stop() uses TLS from owner_process instead of current_process
This should be using the process instance retrieved within the function,
and not g_current_process, otherwise this is potentially comparing
iterators from unrelated vma_map instances (which is undefined
behavior).
While likely very uncommon, this sanitizes the input and does nothing in
the event of the length being equal to or less than zero, avoiding
constructing a std::string when there's no need to. It also avoids an
out-of-memory scenario, as a negative value would wrap around to its
equivalent unsigned representation in std::string's constructor.
e.g. If someone was silly and a length of -1 was specified, this would
make a string with a length of 0xFFFFFFFFFFFFFFFF on a 64-bit platform,
which will obviously eventually fail due to the allocation being way too
large.
* kernel/event: Make data members private
Instead we can simply provide accessors to the required data instead of
giving external read/write access to the variables directly.
* fix compile error
