How to use it?

[fjtrujy]

Hello,
Not sure if this should be an issue but I have been giving a try and reading into the internet but I didn't find a way to make it work.
Basically I would like to be able to debug our PS2 elf applications. The main functionality that I see as a must-have to have breakpoints and a way to inspect the value of variables.

Do we have more information about how to use it? In this case, should we improve our Readme?

Pinging @sp193 because most probably he is the one that knows more about this.

Thanks

[sp193]

I've never used this before. And until today, I never looked at the code here either.

From ps2gdbStub.c, we have a comment that explains how to use it:
This project no longer contains a main function. Instead, link it into your own project and call gdb_stub_main from your own main function.

The code depends on ps2ips.irx, which means you need ps2ip.irx and friends too. It does not support debugging IOP modules.

[pedroduarte0]

Hi,

Back in 2009 (time flies!) under the nickname of cosmito I have posted in forums.ps2dev.org about my experiences with it. I found the posts in Lukasz's mirror:

http://lukasz.dk/mirror/forums.ps2dev.org/viewtopicb920.html?t=4430
http://lukasz.dk/mirror/forums.ps2dev.org/viewtopicce26.html?t=11075

The second post has a walkthrough of what I did to use ps2gdb.

At the time I managed to get ps2gdb going but there was definitely something odd over there, since when debugging the program execution jumped erractically back and forth when stepping though the statements. Possibly was some PS2 MIPS specific architecture different that caused it - but gdb on the PSP did worked fine, as I had (still have) a PSP and have tried it.

One of the main reason I stop doing dev for the ps2 was the fact there wasn't a way to do proper interactive debugging, so no immediate way of getting a callstack during execution, for example. Using printf becomes way to time consuming so I got sick of it.

Perhaps someone wants to continue where I stopped.

[fjtrujy]

Hello @pedroduarte0,
Yes, I went through these threads when I was investigating it a time ago.

Based on my poor knowledge and how it is working in PSP, I think that most probably is the best starting point to make this work.

What PSP has is:

1. The GBD Binutils patched (probably most difficult part). We don't have gdb ported....
2. A powerful psplinkusb. We currently just have a ps2link that contains less functionality than these PSP specific ones.

I hope that @sp193, @cosmito, @mlafeldt or @lukaszdk could bring some light here, as least for clarifying how this should work.

Thanks

[sp193]

I did debugging with the DSNET tools (over DECI2), not with GDB. Sony-licensed developers used DSEDB and DSIDB, to interface with the debuggers within the EE and IOP kernels. The IOP kernel has no DECI2 manager loaded in CEX and DEX by default, but the EE kernel has the EE-side DECI2 manager (and hence the debugger) integrated into it.

Before I got my DTL-T10000H, I created RDB, based on some components from Silverbull's Kermit ODEM project. It functions similarly to the Sony TDB startup card. While the stock CEX/DEX kernel has no support for the thread extensions (thread debugging commands like dt don't work), it's possible to provide the TDB startup card's kernel for RDB to load.

As for IOP side debugging, that's not so easily supported because it is more complicated; the IOP to HOST driver must be capable of operating, even when threads are suspended. Otherwise, the PS2 will hang when DSIDB pauses thread execution.
It's for this reason that the Sony TDB startup card does not support DSIDB, since its "TIF" driver involves a hack to send messages over their network stack, which runs in user land.

[fjtrujy]

Thanks @sp193 for you info.
I'm trying to make it work, and somehow with the help of @psxdev and after make some changes in the repo, we achieved something:

#include <stdio.h>

int gdb_stub_main( int argc, char *argv[] );

static int counter = 0;

void printHello() {
       printf("Hello world! counter = %i\n", counter);
}

void afterPrint() {
       counter ++;
}

int main(int argc, char *argv[] )
{      
       printf("Starting gdb_stub_main!!!\n");

       gdb_stub_main(argc, argv);

       printf("Finished gdb_stub_main!!!\n");

       while(1) {
              printHello();
              afterPrint();
       }

       return 0;
}

With this example, I was trying to put a breakpoint and inspect the value of the counter variable.

(gdb) p counter
$15 = 0x2

(gdb) p counter
$17 = 0x3

So, it more or less looks to be working, however, I think that it isn't ready to be used on a daily basis.

Thanks

[pedroduarte0]

Indeed thanks @sp193 for insight on how things worked out on your case.
And speaking on 'insight', at the time, after getting ps2gdb running, I remember to have used Insight on Linux as a GUI tool to interact with it as it connects through network to the gdb server on the PS2. Here was evident that for this purpose the current network stack was a huge bottleneck... Something as just stepping through would take around 10 - 20 seconds. I think Insight may be requesting quite some information all the time, such as callstack and variables, as it is just too much for the network stack running at the IOP.

But still, I came across the oddness of when stepping though the instructions, the callstack would erratically advance back and forth... Might be that ps2gdb is not properly patched to support the modified MIPS processor used by the PS2.

I also attempted to use the network stack from SMS Media Player which is faster than the ps2sdk one but somehow I didn't managed to have success there. I bet there would be someone more experienced than me into the low level aspects of the PS2 that could make it.

So I see some options:

1. Attempt to find out the cause for the erractic behavior of ps2gdb and fix it (perhaps the PSP version can provide some insight)
2. If 1 is achieved, optionally make ps2link use the network stack from SMS Media Player for improved network performance (not sure if the sources are still available and if still compiles with the current sdk)
3. Alternatively write down a dedicated debugger which minimizes network usage (I have no idea of the difficulties, but I assume it can be a resonable complex project... I never delve into the theory of debuggers but would be a matter of registering some processor handlers and interpreting registers and debug information payload of an ELF?)

At the time there was in development a project called PS2rd (https://github.com/mlafeldt/ps2rd) on remote debugging but targeted to the gaming side. I can see @mlafeldt was involved.

Regarding the network stack, I wonder how would be possible to have a network stack completely running on the EE, and the limitations. Would it be possible to have it running on a thread? How would the client applications interact with it? How would it be its resiliency against being stopped/destructed by other applications running on the EE? Do you know some of these answers @sp193 or @mlafeldt ?

[sp193]

I cannot really comment on why GDB isn't working well, but I can comment on LWIP because I have spent time between 2012-2017 to improve the networking aspect of our PS2SDK.

Personally, I think running LWIP on the IOP should have been OK. I mean, it worked for Sony, when they made the TDB startup card. And it also worked great when I was using RDB. So something must have not worked right.
If it's due to CPU utilization on the IOP, this can be monitored with THMON, although there is a need to pair the right version with the IOP kernel used.

I ported LWIP 1.4.1, then 2.0.0 to the PS2SDK. It can be run from either the EE or IOP, depending on the developer's needs. To provide an interface between the EE and IOP options, the PS2SDK's SMAP driver is registered with NETMAN (NETwork MANager). NETMAN also provides APIs to control and monitor the network interface, which includes the ability to override the link operation mode.
Thanks to @rickgaiser showing me how to do it properly, we can get about 7MB/s (due to the IOP bottleneck) when LWIP is running on the EE, with the standard module design that Sony used. When on the IOP, I remember it's about 2.4MB/s.

The old versions of DEV9 and SMAP were previously plagued by a few problems, such as lacking DMA support and hardware-specific logic from Sony. LWIP needed to be patched to properly support our kernel functions. For example, our kernel functions like SignalSema cannot be run from an interrupt-inhibited state, which LWIP doesn't abide by. We're also using cooperative multitasking, which LWIP wasn't originally well-designed for. The SMAP itself (on seemingly all models) seems to have a hardware bug, whereby the Rx FIFO may hang up under heavy load. There is a need to work around this in software.

I may have forgot the significance of it, but I recall that LWIP v2.0.0 was a better fit for the IOP, compared to the older versions. They made the core locking feature a stable feature, which helped the IOP drastically because it reduced the number of context-switches. As a result, I recall seeing that its performance is even ahead of SMSTCPIP's (but perhaps not its footprint).

By the way, I have also observed that some network adaptors (e.g. my Realtek RTL8102E) do not seem to support Ethernet flow control with the official Realtek driver, as of 2017. If such a device is connected to the PS2's network adaptor, performance may become poor during bulk data transfers because the IOP cannot keep up - but yet there's no support for flow control to slow down the sender. If we limit the window size, performance also goes down. I think there isn't a nice way to handle this scenario, other than putting another device between the PS2 and the PC.

I don't think that SMSTCPIP is issue-free. We're using it in OPL, but despite spending time to backport patches from LWIP to it, it has been reported to still occasionally freeze up under specific conditions.

[pedroduarte0]

Thanks for the update @sp193, since you worked from 2012 onwards and I left in 2011 I did experienced the old stack, not the improvements you mentioned above. So perhaps performance should be certainly better now. Great work indeed!

[Retropnda]

Hola,

Allá por 2009 (¡el tiempo vuela!) bajo el apodo de cosmito publiqué en forums.ps2dev.org mis experiencias con él. Encontré las publicaciones en el espejo de Lukasz:

http://lukasz.dk/mirror/forums.ps2dev.org/viewtopicb920.html?t=4430 http://lukasz.dk/mirror/forums.ps2dev.org/viewtopicce26.html?t=11075

La segunda publicación tiene un recorrido de lo que hice para usar ps2gdb.

En ese momento logré poner en marcha ps2gdb, pero definitivamente había algo extraño allí, ya que al depurar, la ejecución del programa saltaba erráticamente de un lado a otro al pasar por las declaraciones. Posiblemente fue una arquitectura específica de PS2 MIPS diferente la que lo causó, pero gdb en la PSP funcionó bien, ya que tenía (todavía tengo) una PSP y la probé.

Una de las principales razones por las que dejé de hacer desarrollo para la ps2 fue el hecho de que no había una manera de hacer una depuración interactiva adecuada, por lo que no había una forma inmediata de obtener una pila de llamadas durante la ejecución, por ejemplo. Usar printf se convierte en una forma de consumir mucho tiempo, así que me cansé.

Tal vez alguien quiera continuar donde me detuve.

Actualmente desarrollo en la ps2 veo que usted sabe del tema y conosi a cosmito almenos algunos proyectos como Doom y quisiera preguntar si podemos charlar del tema

[AKuHAK]

example on how to use it (source here)

[cosmito]

Awesome!