-
Notifications
You must be signed in to change notification settings - Fork 81
Ideas
Below are some major and minor tasks for the VitaSDK project (including but not limited to vita-toolchain). They are a good starting point for getting into helping the Vita homebrew community. The tasks are sorted by difficulty then by priority. Items marked (*) means it is recommended you actually own a hacked Vita to test with.
These are simple tasks that will take no more than a couple hours of work after getting familiar with the project. As such, they are a good way to learn how vitasdk works.
https://github.com/vitasdk/vita-toolchain/issues/114
The internal structure for module exports (and probably imports) is wrong. It defines the size field as a two byte integer but it should be one byte. The reason for this mistake was the second field was always zero in examples we've seen. Changing the struct definition should be enough, but it might break other stuff so it's good to see every place that field is used and check that it doesn't introduce any new buggy behavior.
https://github.com/vitasdk/vita-headers/issues/113
We don't have much newbie-friendy guides and the next person who starts from zero-knowledge should document what they do (setup, build, etc) so people can find their way easier.
https://github.com/vitasdk/vita-toolchain/issues/89
For some reason, if we do not align code segments to 0x1000, it doesn't work on the Vita. There doesn't seem to be any problem in the Vita's loader but some issue with how the ELF is laid out which confuses the Vita. Setting alignment to 0x1000 mitigates the issue but this results in bloated ELF files (when not compressed). It would be nice to figure out the root cause and fix it. This might be more work than estimated due to the unknown nature of the cause.
Due to how strip works, relocation information (needed by vita-elf-create) is stripped along with debug info and symbols. The task here is to figure out a way of invoking strip correctly or patching strip to work with vitasdk and including it in our build scripts.
Update the newlib with the latest upstream. This should just be merging our changes with the latest newlib.
https://github.com/vitasdk/vita-toolchain/issues/48
This is a simple yet annoying one. Early on, we used "module" and "library" to mean different things and later on swapped the definitions. Even though this was confusing, we agreed it was more consistent with other usage of these terms. This change was made early on so most people don't even know about this but there might be older references in the code that uses the old meaning (like names of structs and variables and such). This would be a good excuse to read through all the source code and fix the names.
These are tasks that will require good familiarity as well as time, but are not structurally complex.
https://github.com/vitasdk/vita-headers/issues/271
There are a couple of issues with how the NID database works today. The first is that we do not support de-mangled C++ names. The database served the dual purpose in documentation reversed Vita functions as well as used in linking homebrew. If we store the mangled name, it works for the second purpose (this is what we currently do). If we store the de-mangled name, it works for the first purpose, but we would need extra work in vita-elf-create to generate the right mangled names.
Another issue is that certain symbols (specifically in SceLibc) collide with newlib and thus cannot be included in the database. We need some mechanism to "ignore" them in the stub creation or some other way to resolve this problem.
We can also play around with db.yml improvements such as seeing if we can introduce additional information to the database (such as comments or call prototypes) that might help in reverse engineering or other non-linking tasks that uses the db.
https://github.com/vitasdk/vita-headers/issues/108
We reversed many kernel functions that have not made it into db.yml. We should write a script that can scrape the NIDs from the HENkaku wiki and update the db.yml accordingly. This would mostly help keep things consistent.
Currently autobuilds in travis takes multiple hours because it always builds an entire toolchain (binutils, gcc, etc) from scratch when anything changes. Most components like binutils/gcc hardly change and most of the time it's only the vita-toolchain or vita-headers that change. We should identify these cases and not rebuild everything.
https://github.com/vitasdk/vita-toolchain/issues/47
vita-elf-create is pretty complex and not really tested. We should write unit tests for key functions based on the kinds of legal ELFs. The implementation is expected to know or learn the ELF format well enough to understand what goes into the tests.
Several things such as C++ exceptions and std::thread don't work unless some workaround is used so that pthread_init() is called on main thread. This should be fixed as this is inconvenient.
These are significant tasks that require domain specific knowledge as well as time to build a complex system.
This is an endless task as we try to gain more knowledge on how the system works in order to build a better SDK. The main task here is just reading assembly code dumped from the Vita, reversing function prototypes, and documenting how things work. We hardly have any info on low-level IO and drivers.
https://github.com/yifanlu/taiHEN/issues/70#issuecomment-312035527
taiHEN is a system level function hooking and patching system. It allows us to write mods to system modules without having to modify any existing (signed) code on the system. Currently, it allows us to "hook" function calls as well as "inject" code/data arbitrarily. We would like to extend the system to support running code at predefined "events" (such as when a new module is loaded).
This requires first reverse engineering Vita GPU (SGX543MP4+)'s shaders or the shader compiler. This itself is a lot of work. Then build a compiler for it in Cg.
We have a gdb port in progress however it lacks features for setting watchpoints or finding more thread information. Such tasks requires reverse engineering the Vita kernel to understand how the kernel handles memory management and threads. We also need to improve network latency for gdb which requires reverse engineering the network stack to figure out why kernel sockets are so slow.
Not the easiest, but probably one of the coolest challenges. Currently the toolchain can break without us knowing when changes are introduced (especially to newlib). Indeed samples are compiled, but no further tests are run.
This task has several components:
- Create unit tests that can be run on a real Vita to make sure that the different APIs behave properly.
- Design a server homebrew that listens, run executables that it receives, and send back the output or the crash dump. It needs to be robust enough so that it recovers from most crashes (exception handler), and automatically restart if a unrecoverable hangup is detected.
- Run this homebrew on a real PS Vita (PSTV is advised) and expose it to the internet. Some authentication mechanism should be put in place to avoid usage by malicious parties. A NAND backup is recommended so that any serious error can be recovered from.
- Integrate it into Travis-CI so that the unit tests are run every time a modification is made to the toolchain (and maybe the SDK).