aboutsummaryrefslogtreecommitdiff
path: root/doc/dev_notes.md
diff options
context:
space:
mode:
authorJohn "Lameguy" Wilbert Villamor <lameguy64@gmail.com>2022-03-25 09:22:20 +0800
committerGitHub <noreply@github.com>2022-03-25 09:22:20 +0800
commit975e614b3c840e2f717adac1d1cb9cee4e5e561b (patch)
tree6584ce5b0dbe27a466c95c81fac61b0d90f627bd /doc/dev_notes.md
parent05d44488bd5587786f4bd0286fc0f555c79aa46a (diff)
parent45168ae43e29aa5930ee5a206475ae836078915f (diff)
downloadpsn00bsdk-975e614b3c840e2f717adac1d1cb9cee4e5e561b.tar.gz
Merge pull request #46 from spicyjpeg/psxmdec
Critical ldscript fixes, initial MDEC support and CI updates
Diffstat (limited to 'doc/dev_notes.md')
-rw-r--r--doc/dev_notes.md59
1 files changed, 31 insertions, 28 deletions
diff --git a/doc/dev_notes.md b/doc/dev_notes.md
index 3aa2304..a96d6ef 100644
--- a/doc/dev_notes.md
+++ b/doc/dev_notes.md
@@ -14,20 +14,20 @@ _- spicyjpeg_
## MIPS ABI / compiler
-- When calling C functions (ie. BIOS functions) from assembly code you'll need
- to allocate N words on the stack first when calling a function that has N
- arguments (`addiu $sp, -(4*N)` where N = number of arguments of the function
- being called) even if the arguments are on registers `a0` to `a3` and the C
- functions don't always use the space allotted in stack. When calling a
- function with a variable number of arguments (`printf`) always allocate 16
- bytes of stack.
+- When calling C functions (including BIOS functions) from assembly code you'll
+ need to allocate one 32-bit word on the stack for each argument the function
+ takes (`addiu $sp, -(4*N)` where `N` = number of arguments of the function
+ being called), *even if the function takes its arguments from registers*
+ *`$a0`-`$a3` rather than from the stack*. When calling a variadic function
+ (i.e. one with a variable number of arguments, such as `printf`) always
+ allocate 16 bytes of stack.
- For some reason `mipsel-unknown-elf-nm` and `mipsel-none-elf-nm` (symbol map
generators) insist on outputting 64-bit addresses (with the top 32 bits set,
- e.g. `FFFFFFFF80010000`) even when feeding it a regular 32-bit MIPS
- executable, while the standard x86 nm tool that ships with most GCC packages
- prints the proper 32-bit address. Unclear whether this is a bug, intended
- behavior or the result of some ancient ELF ABI flag crap.
+ e.g. `FFFFFFFF80010000`) even when feeding them a regular 32-bit MIPS
+ executable, while the standard (x86) `nm` tool that ships with most GCC
+ packages prints the proper 32-bit address. Unclear whether this is a bug,
+ intended behavior or the result of some ancient ELF ABI flag crap.
`DL_ParseSymbolMap()` will ignore the top 32 bits, so this should only bother
you if you're implementing your own symbol map parser.
@@ -162,9 +162,26 @@ _- spicyjpeg_
multiple times) and uses the same variable values as the main project,
however CMake will *not* pass custom variables through by default. If your
toolchain script has options that can be set via custom variables (like
- `PSN00BSDK_TC` and `PSN00BSDK_PREFIX` in PSn00bSDK), you'll have to set
+ `PSN00BSDK_TC` and `PSN00BSDK_TARGET` in PSn00bSDK), you'll have to set
`CMAKE_TRY_COMPILE_PLATFORM_VARIABLES` to a list of variable names to be
- exported to generated dummy projects.
+ exported to generated dummy projects. Additionally you may need to set
+ `CMAKE_TRY_COMPILE_TARGET_TYPE` to `STATIC_LIBRARY` to prevent CMake from
+ invoking the linker.
+
+- When `project()` is called, CMake uses the value of `CMAKE_SYSTEM_NAME` to
+ determine default values for several variables and properties. Most of these
+ defaults are undocumented: e.g. setting the system name to `Generic` (as
+ suggested by the docs for bare metal targets) will result in CMake assuming
+ that the target platform does not support dynamic linking, so you'll have to
+ turn it back on by setting the `TARGET_SUPPORTS_SHARED_LIBS` global property
+ *after* invoking `project()`.
+
+- It is not possible to use custom toolchains (through toolchain files or by
+ setting `CMAKE_*_COMPILER` manually) with any of the Xcode or VS generators,
+ as their respective build systems handle compiler selection internally rather
+ than relying on variables passed by CMake. Ninja or `make` is thus always
+ required to build PSn00bSDK and any projects made with it, even if the
+ host-side tools are built using Xcode or MSVC.
- There is no way to use multiple toolchains (PS1 + host) in a single project,
even if you use `add_subdirectory()` to execute multiple project files
@@ -220,20 +237,6 @@ _- spicyjpeg_
endforeach()
```
-- Depending on how you find external dependencies (`find_package()`, vcpkg,
- pkg-config...), CMake may end up outputting an executable that relies on a
- DLL installed system-wide. To correctly install the DLL alongside the
- executable you have to specify a regex as follows:
-
- ```cmake
- install(
- TARGETS my_executable
- RUNTIME_DEPENDENCIES
- PRE_EXCLUDE_REGEXES ".*"
- PRE_INCLUDE_REGEXES "tinyxml2"
- )
- ```
-
CMake will scan the executable at install time and copy all the required DLLs
that match the second regex. If no regex is specified CMake will also copy OS
DLLs like `libc` or `msvcrt`, which usually isn't the desired behavior.
@@ -277,4 +280,4 @@ _- spicyjpeg_
space.
-----------------------------------------
-_Last updated on 2021-11-28 by spicyjpeg_
+_Last updated on 2022-02-06 by spicyjpeg_