Thanks, I managed to build the project. I had to install PS2SDK again. But when I try to load it on PCSX2 it freezes with the following log messages: Spoiler: LOG MESSAGE HLE Host: Set 'host:' root path to: C:\Users\jhona\Desktop\COMPILADO NOVO\ Opening plugins... Opening GS Opening PAD Opening SPU2 Current Renderer: Direct3D9 (Hardware mode) Intel(R) HD Graphics 4000 (10.18.10.4252) Opening CDVD Opening USB Opening FW Opening DEV9 McdSlot 0 [File]: C:\Users\jhona\Documents\PCSX2\memcards\Mcd001.ps2 McdSlot 1 [File]: C:\Users\jhona\Documents\PCSX2\memcards\Mcd002.ps2 Plugins opened successfully. Bios Found: USA v01.60(07/02/2002) Console BIOS rom1 module not found, skipping... BIOS rom2 module not found, skipping... BIOS erom module not found, skipping... # Initialize memory (rev:3.63, ctm:392Mhz, cpuclk:294Mhz detected) PlayStation 2 ======== Hard reset boot ROMGEN=2002-0207, IOP info (CPUID=1f, CACH_CONFIG=0, 2MB, IOP mode) <20020207-164243,ROMconf,PS20160AC20020207.bin:11552> # Total accessable memory size: 32 MB (B:2:8:0) (363:2:7c30) # TLB spad=0 kernel=1:12 default=13:30 extended=31:38 # Initialize Start. # Initialize GS ... # Initialize INTC ... # Initialize TIMER ... # Initialize DMAC ... # Initialize VU1 ... # Initialize VIF1 ... # Initialize GIF ... # Initialize VU0 ... # Initialize VIF0 ... # Initialize IPU ... # Initialize FPU ... # Initialize User Memory ... # Initialize Scratch Pad ... # Initialize Done. EE DECI2 Manager version 0.06 Feb 7 2002 16:41:20 CPUID=2e20, BoardID=0, ROMGEN=2002-0207, 32M found 49788 symbols ELF (host:C:\Users\jhona\Desktop\COMPILADO NOVO\snes9x.elf) Game CRC = 0x01050B37, EntryPoint = 0x001000D8 IOP Realtime Kernel Ver.0.9.1 Copyright 1999 (C) Sony Computer Entertainment Inc. Reboot service module.(99/11/10) cdvd driver module version 0.1.1 (C)SCEI Load File service.(99/11/05) Multi Threaded Fileio module.(99/11/15) iop heap service (99/11/03) loadelf: fname host:C:¥Users¥jhona¥Desktop¥COMPILADO NOVO¥snes9x.elf secname all loadelf version 3.30 Input ELF format filename = host:C:¥Users¥jhona¥Desktop¥COMPILADO NOVO¥snes9x.elf 0 00100000 003a6f88 ........................................................... Loaded, host:C:¥Users¥jhona¥Desktop¥COMPILADO NOVO¥snes9x.elf start address 0x1000d8 gp address 00000000 # Restart Without Memory Clear. # Initialize GS ... # Initialize INTC ... # Initialize TIMER ... # Initialize DMAC ... # Initialize VU1 ... # Initialize VIF1 ... # Initialize GIF ... # Initialize VU0 ... # Initialize VIF0 ... # Initialize IPU ... # Initialize FPU ... # Initialize Scratch Pad ... # Restart Without Memory Clear Done. read/write allocate memory 4000 argv[0] = host:C:¥Users¥jhona¥Desktop¥COMPILADO NOVO¥snes9x.elf (EE pc:00303078) TLB Miss, addr=0x0 [load] (EE pc:0030315C) TLB Miss, addr=0x0 [load] (EE pc:00302E30) TLB Miss, addr=0x0 [load] Get Reboot Request From EE ROM directory not found PlayStation 2 ======== Update rebooting.. PlayStation 2 ======== Update reboot complete IOP Realtime Kernel Ver.0.9.1 Copyright 1999 (C) Sony Computer Entertainment Inc. Reboot service module.(99/11/10) Load File service.(99/11/05) Multi Threaded Fileio module.(99/11/15) iop heap service (99/11/03)
The usual ways: Leave debug symbols in the ELF (don't add the -s linker option nor strip with ee-strip) and compile with the -g compiler option. Use ee-addr2line to get the line number of the fault from the exception program counter (EPC). Add more printf() statements around, to locate the point of failure. Do a static check of your code, to look out for bad coding practices and mistakes. Variables should always be initialized somewhere before use.
Depending on what version of pcsx2 you are using it may not run at all. For a long time when using the latest dev builds and homebrew that used host: did not run as host is/was not a valid device in pcsx2.
Commands are usually sent through the MRP device (the interplane of the TOOL connecting the PC and the PS2) or through the network (for RDB on retail/TEST PS2 or dsnetm). It may be possible to use Kermit's dsnetm to also send commands through IEEE1394 or EE SIO.
Retdec has added support for a few more MIPS instructions: https://github.com/avast-tl/retdec/commit/bfd6efb255f8bcaf60cba524ae56f66afdcf5645 Debug information does wonders for the output of Retdec. The dsnet binaries do not have the STABS debug information stripped, but retdec does not support STABS; only DWARF and PDB are supported. No debug information: Code: // Address range: 0x804983b - 0x80498ef int32_t parse_memlimit(int32_t a1) { // 0x804983b char v1; g6 = v1; char * str; int32_t len = strlen(str); // 0x8049857 int32_t v2; unsigned char v3; if (len == 0) { // 0x80498ad v2 = str_to_uint64(a1, str, 0, 0, -1, -1); // branch -> 0x80498cc // 0x80498cc return hardware_memlimit_set(v2, g6, v1, (int32_t)v3, 0); } int32_t v4 = len - 1; // 0x804986b g6 = v4; char * v5 = (char *)(v4 + (int32_t)str); // 0x8049873 if (*v5 != 37) { // 0x80498ad v2 = str_to_uint64(a1, str, 0, 0, -1, -1); // branch -> 0x80498cc // 0x80498cc return hardware_memlimit_set(v2, g6, v1, (int32_t)v3, 0); } // 0x804987a g6 = v4; *v5 = 0; int32_t v6; v2 = str_to_uint64(v6, str, 1, 0, 100, 0); // branch -> 0x80498cc // 0x80498cc return hardware_memlimit_set(v2, g6, v1, (int32_t)v3, 1); } Yes debug information: Code: // From module: /home/vagrant/xz-5.2.4/src/xz/args.c // Address range: 0x804983b - 0x80498ef // Line range: 34 - 55 void parse_memlimit(char * name, char * name_percentage, char * str, bool set_compress, bool set_decompress) { char * v1 = str; // bp+12 g5 = set_compress; int32_t len = strlen(str); // 0x8049857 int64_t v2; // 0x80498be if (len == 0) { // 0x80498ad v2 = str_to_uint64(name, str, 0, 0); // branch -> 0x80498cc // 0x80498cc hardware_memlimit_set((int64_t)(int32_t)v2, g5 % 2 != 0, set_compress, set_decompress); return; } int32_t v3 = len - 1; // 0x804986b g5 = v3; char * v4 = (char *)(v3 + (int32_t)str); // 0x8049873 if (*v4 != 37) { // 0x80498ad v2 = str_to_uint64(name, str, 0, 0); // branch -> 0x80498cc // 0x80498cc hardware_memlimit_set((int64_t)(int32_t)v2, g5 % 2 != 0, set_compress, set_decompress); return; } // 0x804987a g5 = v3; *v4 = 0; int32_t v5 = *(int32_t *)&v1; // 0x804989714 int32_t v6 = *(int32_t *)&name_percentage; // 0x804989a15 int32_t v7 = str_to_uint64((char *)v6, (char *)v5, 1, 0); // branch -> 0x80498cc // 0x80498cc hardware_memlimit_set((int64_t)v7, g5 % 2 != 0, set_compress, set_decompress); } Notice the readable function variable names, correct types, and correct number of arguments. Also, note the errors with 64-bit integers. Original source code: Code: static void parse_memlimit(const char *name, const char *name_percentage, char *str, bool set_compress, bool set_decompress) { bool is_percentage = false; uint64_t value; const size_t len = strlen(str); if (len > 0 && str[len - 1] == '%') { str[len - 1] = '\0'; is_percentage = true; value = str_to_uint64(name_percentage, str, 1, 100); } else { // On 32-bit systems, SIZE_MAX would make more sense than // UINT64_MAX. But use UINT64_MAX still so that scripts // that assume > 4 GiB values don't break. value = str_to_uint64(name, str, 0, UINT64_MAX); } hardware_memlimit_set( value, set_compress, set_decompress, is_percentage); return; } I know that some games had symbols left in their executables, but has there been any case of IOP modules with symbols in their executables (other than OSDSND in early ROMs)?
How did you get the stab information to pass to retdec? Also retdec only supports 32 bit executables which is why there are errors with the 64 bit integers. I think
It's a decompilation of xz as I used as an example, not the dsnet tools. Also, in the example with no debug information, the 64 bit integer is split into 2 32 bit integers.
I see. I didn't look to closely as I just woke up. I had previously looked into extracting the stab information and formatting it to pass to retdec but came up empty handed. Stab doesn't seem to be documented too well which is praprobaa reason for the lack of support.
If you meant Sony IOP modules, then no... they've been pretty consistent from what I have seen. Maybe it was also because they designed their modules to have the most correct behaviour with as little space wasted as possible, so as to not add onto resource overhead. Which makes sense, since their modules go into ROM and also make up a SDK. The OSDSND case might have been because they were rushing to complete the SPU2 and its libraries. OSDSND is also known as rspu2drv, the tentative sound library. The only other module that I've seen which is abnormally large, is ILINK.IRX. But I never found one with symbols. It has a lot of code, seemingly because they compiled with O0 and have assertions everywhere. On the other hand, there are IOP modules with debugging information within games. Like with plain ELFs, they could have symbol information stripped out (or not). Sometimes we get lucky and a bugged game still has symbols left behind.
You two gentlemen are aware that I have been working on the translation port of the PS2 version of Fate/Stay Night [Realta Nua]. The reason I asked about the stabs information is because that while pcsx2 and ps2dis don't see the the symbol table there are in fact mangled c++ symbols present in the game. I am fairly certain that there is also stab information present but I have no idea how to get at it or even how to put it to use. Also the actual point of replying which I forgot. There are a handful of instructions the PS2 uses that capstone doesn't have. Notably the paddu instruction that most games start out using to clear the system registers. When capstone doesn't know of an instruction retdec simply skips over it and pretends it wasn't there.
To check the if there is STABS information, use objdump -h /path/to/executable/file and check for .stabs section. If it is there, that means the file has STABS debugging information. I noticed that Retdec doesn't decompile the newer OSDSYS correctly; it just decompiles 2 functions. This issue might help in implementing more instructions: https://github.com/avast-tl/retdec/issues/393 For HOSDSYS, it seems like the first 512 bytes of FNTOSD/ICOIMAGE/JISUCS/SKBIMAGE/SNDIMAGE/TEXIMAGE are obfuscated. The rest after that look like a decrypted RESET/IOPRP structure. Anyone know how to deobfuscate the first 512 bytes? I couldn't find any cross-references.
It does the same thing for ps2-packer compressed elfs. This is because it doesn't know how to detect compressed ps2 elfs nor how to unpack them. I noticed this yesterday when attempting to decompile esr. I had to manually unpack it with the old ps2unpacker and pull some parts from memory in pcsx2. Unfortunately as far as that issue on the retdec page goes I definitely agree with their standing on only wishing to have standard instructions implemented. I had actually attempted to write my own decompiler using capstone for the vita and ps2 but have shelved it at the moment. One could create a fork of retdec and add the instructions but I doubt it would ever be merged. As long as the instruction translates to llvm ir nicely it should work out.