A call through a still-pending import gets written as a generic "invalid
syscall" opcode (WriteFuncMissingStub) that no longer carries the
original module name or NID by the time it's actually invoked - but the
address of the syscall instruction itself is exactly the stubAddr every
pending FuncSymbolImport already records. Added
KernelFindImportByStubAddr() to search loaded modules' importedFuncs for
a match, and use it in GetSyscallFuncPointer's unknown-syscall path.
Co-Authored-By: Claude Sonnet 5 <[email protected]>
Common and basis_universal call zstd functions directly but never
declared the dependency after being split into their own
CMakeLists.txt files, relying on directory-scope include_directories()
that no longer reached them. Worked on Linux via system zstd.h, but
broke the Android NDK build which has no such fallback.
Co-Authored-By: Claude Sonnet 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01XMv4XdM5dThs9Avr5FPXRv
gason, vma, cityhash, 7zip (ext/lzma-sdk), basis_universal, pugixml,
kirk (ext/libkirk), sfmt19937, xbrz, and xxhash were each defined with
a small add_library() block directly in the root CMakeLists.txt, even
though ext/CMakeLists.txt already exists and handles every other vendor
library (freetype, imgui, naett, discord-rpc, libchdr, zstd, miniupnp,
armips, glew, snappy, ...) via add_subdirectory(). Gave each one its
own ext/<name>/CMakeLists.txt to match that established pattern; xxhash
stays a loose file pair in ext/ (it never had its own directory) so its
add_library() lives directly in ext/CMakeLists.txt instead.
ext/libkirk/CMakeLists.txt already existed but was dead - nothing
add_subdirectory()'d it, and its source list was stale (missing
amctrl.c/.h, which the live inline definition in root had). Replaced
its contents with the current, correct list instead of leaving two
diverging definitions around.
Dropped several target_include_directories()/include_directories()
calls that came along with these (e.g. cityhash, kirk, xbrz, xxhash,
and the lzma-sdk one for 7zip): traced their actual consumers and found
each library's own sources resolve their sibling headers via the
default same-directory quote-include rule, and every external consumer
already uses the full "ext/<name>/..." path resolved through the global
root include - so these were dead weight regardless of position.
Replaced two single-value alias variables (LIB7ZIP_LIBRARY, always
"7zip"; BASISU_LIBRARIES, always "basis_universal") with their target
names directly in Common/CMakeLists.txt, rather than trying to carry
them across the new add_subdirectory boundary - plain set() variables
don't propagate back up out of a child scope without PARENT_SCOPE, so
keeping them as-was would have silently broken Common's link line.
Verified with a fully clean rebuild (removed build/ entirely), a
HEADLESS=ON UNITTEST=ON build, and a LIBRETRO=ON build.
Co-Authored-By: Claude Sonnet 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01PSNaZnHCjmryS3ziVN9gZU
Same treatment as Common/Core/GPU: move the ppsspp_ui target definition
(kept that name rather than renaming to "UI", since it was deliberately
named that in a previous commit) into UI/CMakeLists.txt, pulled in via
add_subdirectory(UI). Source paths are now relative to UI/ instead of
prefixed with "UI/".
PPSSPPHeadless and PPSSPPUnitTest already didn't link ppsspp_ui (they
link Core/Common directly) - that's unchanged, just preserved. The main
per-platform binaries (${TargetBin}) and the Android JNI target keep
linking it as before.
add_compile_definitions(USE_DISCORD=1) has to stay in the root file
rather than move into UI/CMakeLists.txt: it only affects targets created
after the call, and add_subdirectory() snapshots the parent's directory
scope at the point it's invoked, so the definition needs to already be
set before add_subdirectory(UI) runs. Verified UI/DiscordIntegration.cpp
still pulls in Discord_Initialize etc as undefined symbols post-move.
Also removed two now-dead variable inits sitting right next to this
block: "nativeExtra" (never appended to or consumed anywhere anymore,
a leftover from before the old "native" target was removed) and a
duplicate early set(UISource) (the real one now lives inside
UI/CMakeLists.txt's own scope).
Verified with a clean ./b.sh --debug rebuild, a HEADLESS=ON UNITTEST=ON
build (confirmed ppsspp_ui/UI never gets built in that configuration),
and a LIBRETRO=ON build.
Co-Authored-By: Claude Sonnet 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01PSNaZnHCjmryS3ziVN9gZU
Same class of bug as the USE_DISCORD fix: add_compile_definitions() only
affects targets created after the call, but the whole USE_MINIUPNPC block
sat after add_library(Core STATIC ...). That meant Core/Util/PortManager.cpp,
built as part of that same add_library call, never actually saw WITH_UPNP
or any of the other miniupnpc defines - UPnP support was silently compiled
out on every platform.
Split the block: compile definitions and the miniupnpc source-file/include
setup now run before add_library(Core STATIC ...), while building the
bundled miniupnpc target and linking it into Core (which needs the Core
target to already exist) stays after, in its original spot.
Co-Authored-By: Claude Sonnet 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01PSNaZnHCjmryS3ziVN9gZU
Mirrors the earlier Common extraction. The old "core" target folded in
all of GPU/ (~200 files) plus a few ext/ files wholesale; Windows
already treats GPU as its own project (GPU.vcxproj), so GPU/CMakeLists.txt
splits that out too. GPU has a genuine two-way dependency with Core
(Core/System.cpp calls GPU_Init(), GPU/* calls back into Core for
Memory/Config/CoreTiming/etc), so GPU is a CMake OBJECT library: its
object files are always included wherever consumed instead of being
lazily pulled from an archive, avoiding the GNU ld single-pass
archive-ordering problem a two-way STATIC dependency would hit.
Also fixed a few library misattributions discovered while tracing what
each file actually uses:
- GlslangLibs (glslang/spirv-cross) moved from Core to Common, since
it's Common/GPU/ShaderTranslation.cpp and VulkanContext.cpp that
call into it directly. It only worked before because Core happened
to always be linked after Common.
- ZSTD and OPENGL_LIBRARIES/X11_LIBRARIES moved from Core to GPU,
matching where they're actually called (GPU/Debugger/Record.cpp and
Playback.cpp for ZSTD, GPU/GLES for raw gl*() calls).
- GPU also needs Ext::Snappy directly (Playback.cpp calls
snappy_uncompress) and the libretro-common include dir under
LIBRETRO, both previously inherited for free by accident.
Also fixed USE_DISCORD's add_compile_definitions ordering: it was
being defined after ppsspp_ui's add_library call, so the UI target
never actually saw it on non-MSVC platforms.
Co-Authored-By: Claude Sonnet 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01PSNaZnHCjmryS3ziVN9gZU
First step of breaking up the monolithic root CMakeLists.txt: move the
add_library(Common STATIC ...) target definition, and every scattered
target_link_libraries/target_compile_definitions/target_include_directories
call touching it, into Common/CMakeLists.txt, pulled in via
add_subdirectory(Common).
Source paths are now relative to Common/ instead of prefixed with
"Common/". The two files living outside that directory (ext/jpge/*)
use ${CMAKE_SOURCE_DIR}/... instead.
include_directories(Common) stays in the root file rather than moving
into Common/CMakeLists.txt: it's a directory-scope command that needs
to affect targets defined *later* in the root file, and add_subdirectory
scope doesn't propagate upward or sideways, so moving it would have
silently broken unprefixed #includes elsewhere in the project.
add_subdirectory(Common) is placed at the point where the *last*
prerequisite variable it needs (PNG_LIBRARIES, RT_LIB, ATOMIC_LIB, etc.)
is guaranteed already set, not where the old add_library(Common ...)
used to start - some of those are resolved later in the file than
Common's original position was.
Verified with a clean ./b.sh --debug rebuild and a HEADLESS=ON
UNITTEST=ON reconfigure/build.
Co-Authored-By: Claude Sonnet 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01PSNaZnHCjmryS3ziVN9gZU
The Android VR build (ANDROID=true, OPENXR=TRUE) was failing to link
ppsspp_jni with undefined references to xrGetInstanceProcAddr,
xrCreateReferenceSpace, xrEnumerateViewConfigurations, etc. - all called
from Common/VR/*.cpp, which is unconditionally part of Common and always
linked into ppsspp_jni via core.
openxr_loader (built via ext/OpenXR-SDK whenever OPENXR AND NOT
ARMV7_DEVICE) was only ever being added to targetExtraLibs, which just
${TargetBin} - the desktop-style executable - consumes. ppsspp_jni,
the actual Android JNI target Gradle's CMake external native build
uses, never got it. Link it in directly, gated the same way OpenXR is
gated everywhere else in the file.
Co-Authored-By: Claude Sonnet 5 <[email protected]>
Check the ZIM header, dimensions, mip count, allocation arithmetic,
and uncompressed payload size before allocating or copying image data.
This prevents crafted texture files from overflowing the image buffer.
Katharine Chui
Henrik Rydgård
copilot-swe-agent[bot]
AgRichard
Acts1631