[neuralsin]

What

Certain titles perform a process-wide lookup for scripting heap entry points at runtime via dlsym(NULL, "scriptingGetMem") and dlsym(NULL, "scriptingFreeMem") (NIDs ayuoL6Vjz2k and yV45DG6ei28). The entry points were not exported.

This exports scriptingGetMem(alignment, size) and scriptingFreeMem(pointer) from libc, backed by ApplicationHeapAlign_nid_no_patch and ApplicationHeapFree_nid_no_patch. The names are the real symbols, so the NID comes from the name and no APS5_EXPORT alias is needed.

Closes #694.

Tested

Linux: application_heap_tests (asserts the allocator callback gets the size and alignment, and that free reaches it), plus the libc and libs ctest set (71 tests) on the PR rebased onto current main. Windows (MinGW GCC 15.2, Release) run by @popcoder565 reported the duplicate-export failure fixed by dropping the aliases. Not run on a title.

Checklist

• Based on current main; no other open PR implements the same functions
• One topic per PR; follow-ups go in a new PR
• No comments in code except technical debt
• Unimplemented paths throw (NotImplemented_nid_no_patch); silent stubs are listed in TechnicalDebt
• No notes, investigation .md files or images added to the repository (attach them to this PR)
• New third-party code is a submodule built from source
• Generic behaviour, not specific to one title
• Depends on: none
• AI-assisted:

[oneandonlydean]

Which title calls scriptingGetMem, and which console library exports it? #694 doesn't name the title, and if the symbol comes from the title's own modules it doesn't belong in libc. Please also fill in the PR template (Tested, AI-assisted).

[popcoder565]

Native Windows run, since no Windows results were posted. Setup: Windows 10 (19045), MinGW-w64 GCC 15.2.0 (WinLibs r7), Release. Head 39159bb4, merged onto main d70b899 in one build with 38 other PRs that had no Windows run.

libc.prx fails its NID patch on Windows, so the build stops:

FAIL: .../libc.prx: duplicate patched export name: ayuoL6Vjz2k

• scriptingGetMem and scriptingFreeMem are extern "C" and named after the real symbols. The patcher derives ayuoL6Vjz2k and yV45DG6ei28 from those names.
• MinGW exports every global symbol, so libc.prx exports both the plain names and the APS5_EXPORT aliases (ayuoL6Vjz2k_nid_no_patch_cut). Both patch to the same NID.
• Dropping the two APS5_EXPORT lines (and the ExportMacros.hpp include) fixes it on Windows. The patched libc.prx then exports ayuoL6Vjz2k and yV45DG6ei28. The four application_heap_* tests pass, and so does the full suite in that build (519 of 519). I haven't checked Linux with that change.

🤖 Addressed by Claude Code

[adriadam10]

Thanks. Changes needed:

• Windows build breaks (native run by @popcoder565, MinGW GCC 15.2, Release): libc.prx fails the NID patch with duplicate patched export name: ayuoL6Vjz2k. scriptingGetMem/scriptingFreeMem are extern "C" and already named after the real symbols, so the patcher derives the NID from the plain name; MinGW exports every global, so the APS5_EXPORT alias (ApplicationHeap.cpp:240, :245) yields the same NID twice. Drop both APS5_EXPORT lines and the ExportMacros.hpp include; with that the patched libc.prx exports ayuoL6Vjz2k/yV45DG6ei28 and the full suite passes on Windows (519/519 in that build). Please confirm on Linux too.
• @oneandonlydean's question is still open: which title calls scriptingGetMem, and which console library exports it? If it comes from the title's own modules it doesn't belong in libc (see CONTRIBUTING: modules titles ship themselves are not reimplemented). Please answer it in the PR.
• Fill in the PR template (Tested, AI-assisted).
• #1656 touches ApplicationHeap.cpp; list it in Depends on if you build on it, and rebase after it lands.

[github-actions]

Progress report (9f4bd71 → 39159bb)

📈 System libraries: 84.77% (+0.01%, +2 implemented functions)

✅ 2 implemented

Library	Name
libc	scriptingFreeMem
libc	scriptingGetMem

[adriadam10]

Ready to merge from my side, but the PR description fails the conventions check:

• [pr-template] Fill in the pull request template: unchecked: AI-assisted:
• [pr-template] Fill in the pull request template: answer AI-assisted with yes or no

Please fill those template lines in (only you can answer AI-assisted); it merges once they pass.

[oneandonlydean]

Closing: the questions from 10-09 are still open (which title calls scriptingGetMem, and which console library exports it), the Windows build fails on the duplicate ayuoL6Vjz2k export, and the branch conflicts with main. If you decide to continue, please reopen.