mirror of
https://github.com/shadps4-emu/shadPS4.git
synced 2026-03-28 14:39:43 -06:00
ee2bc97248
Some checks are pending
Build and Release / reuse (push) Waiting to run
Build and Release / clang-format (push) Waiting to run
Build and Release / get-info (push) Waiting to run
Build and Release / windows-sdl (push) Blocked by required conditions
Build and Release / macos-sdl (push) Blocked by required conditions
Build and Release / linux-sdl (push) Blocked by required conditions
Build and Release / linux-sdl-gcc (push) Blocked by required conditions
Build and Release / pre-release (push) Blocked by required conditions
* Earlier initialization of elf info. Everything used for elf info initialization comes from the param.sfo, so we can initialize this earlier to have this information accessible during memory init. * Extract compiled SDK version from pubtoolinfo string Up until now, we've been using the game's reported "firmware version" as our compiled SDK version. This behavior is inaccurate, and is something that has come up in my hardware tests before. For the actual compiled SDK version, we should use the SDK version in the PUBTOOLINFO string of the param.sfo, only falling back on the firmware version when that the sdk_ver component isn't present. * Store compiled SDK version in ElfInfo * Limit address space for compiled SDK version at or above FW 3 Sony placed a hard cap at 0xfc00000000, with a slight extension for stack mappings. For now, though stack mappings aren't implemented, there's no harm in keeping a slightly extended address space (since this cap is lower than our old user max). Limiting the max through address space is necessary for Windows due to performance issues, in the future I plan to properly implement checks in memory manager code to properly handle this behavior for all platforms. * Use compiled SDK version for sceKernelGetCompiledSdkVersion I think this is pretty self explanatory. * Log SDK version Since this value is what most internal firmware version checks are against, logging the value will help with debugging. * Update address_space.cpp * Update emulator.cpp * Backwards compatible logging Because that's apparently an issue now |
||
|---|---|---|
| .. | ||
| logging | ||
| support | ||
| adaptive_mutex.h | ||
| aes.h | ||
| alignment.h | ||
| arch.h | ||
| assert.cpp | ||
| assert.h | ||
| bit_array.h | ||
| bit_field.h | ||
| bounded_threadsafe_queue.h | ||
| concepts.h | ||
| config.cpp | ||
| config.h | ||
| cstring.h | ||
| debug.h | ||
| decoder.cpp | ||
| decoder.h | ||
| discord_rpc_handler.cpp | ||
| discord_rpc_handler.h | ||
| div_ceil.h | ||
| elf_info.h | ||
| endian.h | ||
| enum.h | ||
| error.cpp | ||
| error.h | ||
| fixed_value.h | ||
| func_traits.h | ||
| hash.h | ||
| io_file.cpp | ||
| io_file.h | ||
| lru_cache.h | ||
| memory_patcher.cpp | ||
| memory_patcher.h | ||
| native_clock.cpp | ||
| native_clock.h | ||
| ntapi.cpp | ||
| ntapi.h | ||
| number_utils.cpp | ||
| number_utils.h | ||
| object_pool.h | ||
| path_util.cpp | ||
| path_util.h | ||
| polyfill_thread.h | ||
| range_lock.h | ||
| rdtsc.cpp | ||
| rdtsc.h | ||
| recursive_lock.cpp | ||
| recursive_lock.h | ||
| scm_rev.cpp.in | ||
| scm_rev.h | ||
| scope_exit.h | ||
| sha1.h | ||
| shared_first_mutex.h | ||
| signal_context.cpp | ||
| signal_context.h | ||
| singleton.h | ||
| slab_heap.h | ||
| slot_array.h | ||
| slot_vector.h | ||
| spin_lock.cpp | ||
| spin_lock.h | ||
| stb.cpp | ||
| stb.h | ||
| string_literal.h | ||
| string_util.cpp | ||
| string_util.h | ||
| thread.cpp | ||
| thread.h | ||
| types.h | ||
| uint128.h | ||
| unique_function.h | ||
| va_ctx.h | ||