gistfile1.txt

Information for the SDK will be in a single XML file for each software version. This is for portability and compatibility with future tools:

<?xml version="1.0" encoding="UTF-8"?>
<library name="SceIoFilemgr" nid="0xDEADBEEF">
     <module name="SceIoFilemgrForUser" nid="0xDEADBEEF">
          <hint name="header_filename" value="kernel/iofilemgr.h" />
          <struct name="SceIoStruct" typedef="TypeSceIoStruct">
               <var name="field1">
                    <description>Struct field</description>
               </var>
          </struct>
          <func name="sceIoOpen" nid="0xDEADBEEF" return="SceUID">
               <description>Description for sceIoOpen</description>
               <args>
                    <arg name="name" type="const char *">
                         <description>First argument</description>
                    </arg>
                    ...
               </args>
          <var name="SceStdOut" nid="0xDEADBEEF">
               <description>Standard output fd</description>
          </var>
     </module>
     <module name="SceIoFilemgrForDriver" kernel="true" nid="0xDEADBEEF">
          ...
     </module>
</library>

Each system version needs its own XML file since NIDs can (but don't have to) change. The actual format of the XML is not important and having stuff as attribute vs value is not important (do whatever is easy). Just make sure to capture the hierarchy of library -> modules -> function/variable exports.

I'm also imagining that include files and even doxygen documentations can all be generated from the XML file. So the XML should contain enough information to encompass the entire SDK. Please take a look at Sony's SDK help files and include files to see what fields to include in the XML. In theory, we should need nothing more than the XML file to rebuild everything. This is also good since IN CASE sony is anal about us using the SDK names (I'm not sure what legal standings they would have on that), then the XML file can be found in gray areas.

Do not worry too much about creating the XML file. Just make a test one that is large enough to test all cases and give me the specs. I can provide you with complete databases of NID -> names and arguments based on stuff we've reversed.

Tool to generate header includes:

headergen [-k] nids.xml [name ...] output_dir

Parses nids.xml and generates header files for each library import. Optionally accept library names to generate headers for. Otherwise, generates headers for all libraries. Output will be stored in the format of "output_dir/module_name.h". If there is a hint for header filename, they will be stored in "output_dir/hint_filename." If flag -k is specified, also generate header files for kernel-only modules.

Header outputs can be as simple as:

#ifndef SCEIOFILEMGRFORUSER
#def SCEIOFILEMGRFORUSER

#include <scedefs.h> // scedefs.h could define SceUID SceOff etc and be generated along with everything

SceUID SceIoFilemgr_SceIoFilemgrForUser_sceIoOpen(const char *name, int mode, int permissions);
#ifndef sceIoOpen
#define sceIoOpen SceIoFilemgr_SceIoFilemgrForUser_sceIoOpen
#else
#error "sceIoOpen is already defined!"
#endif
// The check above allows for multiple libraries/modules to define the same name provided the user doesn't include both header files.

#endif

Tool to generate SCE sections object:

vitalink [-k] nids.xml objects... output.obj

Takes in ARM compiled .o/.obj objects and generate an additional object file that contains the SCE ELF sections including the module info, export table, and import tables. The tool will parse nids.xml and scan objects to match up ELF symbols with NIDS. Then it will select what modules to import and create the valid import tables and stub functions for these entries. A relocation section may be required in the output.obj to create proper offsets and such. It would also be nice to have position-independent code support (ASLR) since that makes UVLoader's life easier, but it should not be a priority.

Linker script to create ELF:

The .lds script should select the correct sections for each object file (specifically ignoring the strings table and symbols table) along with the right ordering (sceModule comes after the stubs section for example).

(Optional) script to generate FSELF:

This is trivial. Just stick a SCE section on top of the file. Please don't merge this with other tools because sony supports loading ELFs and SELFs. It would just be for completeness.

After all that is done, compiling a vita homebrew should be as simple as (also can be done simply in a makefile):

arm-none-eabi-gcc -C -o main.o main.c
arm-none-eabi-gcc -C -o other.o other.c
vitalink vita-300.xml main.o other.o sceinfo.o
arm-none-eabi-ld -o homebrew -T script.lds main.o other.o sceinfo.o
make_fself homebrew homebrew.self