remotely debugging ps2sdk application

[abdollaramadan]

Hello,
I'm new to ps2dev. I was wondering if there's a way to remotely debug ps2sdk application running on the ps2 from a windows maching (cygwin).
I understand that there's a way of using the gdbserver i wonder if that only works under ps2linux, i don't want to develop under ps2linux, beside my ps2 has no hard disk.
Some search got me to ps2gdb, i don't thoroughly understand how to use, but i think i should compile to get ps2gdbStub.elf and run it on ps2 using ps2link, then use mips64r5900-sf-elf-gdb to debug the ps2gdbStub.elf application. What if i want to debug my own application, should it be compiled somehow like ps2gdbStub.elf (using the same make files for example) then debug it the same way?
The problem now is that the svn version of ps2gdb don't compile, note that i can compile application from http://vghacking.net/vb/showthread.php?p=29217 i wonder if that's because ps2gdb uses ps2ip which is replaced by ps2sdk?
Any help will be appreciated. Thanks for advance.

[Lukasz]

You are correct there is a port of gdb for PS2 by MrHTFord, unfortunately this port is from 2003

http://ps2dev.org/News/2003/News_-_11_August_2003

Since 2003 alot of changes have been made to both ps2sdk and ps2link and I wouldn't be surprised if ps2gdb was no longer compatible with the two. My best suggestion to you is either to try to fix ps2gdb, you can check out the source from Subversion with the following command

Code: Select all

svn co svn://svn.ps2dev.org/ps2/trunk/ps2gdb

Or just use printf and ps2link exception information (if any) like most people do, as PS2 programs are often quite simple and these tools are for the most part powerful enough for debugging. I written a couple of tutorials on how to use the exception information to find bugs.

http://lukasz.dk/playstation-2-programm ... debugging/
http://lukasz.dk/playstation-2-programm ... on-screen/

[abdollaramadan]

It's a bit disappointing, but thank you Lukasz.

[cosmito]

I've check-out the ps2gdb sources and actually it was very simple to build it.

The makefile is expecting the existence of a lib folder at the root of the project. So create an empty 'lib' there.
After typing make, you should have a libps2gdbStub.a in there.

But for me, this stops here... I don't know how to use the libps2gdbStub.a lib. Accordingly to the ps2.cmd, there should be a ps2gdbStub.elf...
But the makefile only has building instructions for the lib. What's next?

Also check :
http://ps2dev.org/PS2/Tools/Debugging_t ... st_release

[abdollaramadan]

your post made me look at the make files, and some of the code, i changed a little, and now i can get the elf file, i'm not sure of the legalty of posting the modified files here, but once i execute the file using xlink, i get an exception.

[cosmito]

your post made me look at the make files, and some of the code, i changed a little, and now i can get the elf file, i'm not sure of the legalty of posting the modified files here, but once i execute the file using xlink, i get an exception.

As long the files don't have any copyright I see no trouble of posting them. But you can always post instructions to achieve what you did.

If you got an exception, try the Lukasz tutorials.

Personally, I would like a lot to have a more powerful debugging method than using printf and the ee-addr2line method Lukasz described, since it's only effective at crash level, and doesn't allow to set breapoints and step into those. But I just feel I'm not up to the task of develop a nice debugging system, so I just hope anyone better than me would do the trick :)

[abdollaramadan]

for svn://svn.ps2dev.org/ps2/tags/ps2gdb
those changed i haven't thought of much, i just looked at the samples with ps2sdk, and figure out from the errors.
Makefile.eeglobal:
changed:
EE_INCS := -I$(PS2SDK)/ee/include -I$(PS2SDK)/common/include -I. $(EE_INCS)

EE_LDFLAGS := -nostartfiles -Tlinkfile -L$(PS2SDK)/ee/lib $(EE_LDFLAGS)

EE_ASFLAGS := -EL -G0 $(EE_ASFLAGS)

EE_LIBS += -lc -ldebug -lkernel -lps2ip

in the ee folder:
crto.s

lines 51, 52 replaced CONF_R5900_BPE with 1 << 12

in the makefile

commented line 5
line 11 would be
EE_LDFLAGS += -Wl,-Map,ps2gdbStub.map -L. -L../lib #-L$(PS2IP)/ee/lib

in ps2gdbStub.c
i added the
#include <debug.h>

[cosmito]

But what project does this belong?

[abdollaramadan]

that's about ps2gdb. :)

[cosmito]

Some weeks ago I managed to get some progress.

I've found this thread where megaman show how to use regular linux gdb with a patched version of ps2gdb :
http://forums.ps2dev.org/viewtopic.php?t=4430

So I've apply the patches to the sources of svn://svn.ps2dev.org/ps2/trunk/ps2gdb (it was the first time I had to work with patched under linux) and it compiled fine.

Accordingly to ps2gdbStub.c : "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." - so that's why there is no ps2gdb.elf file anymore, just the library libps2gdbStub.a to be linked to your target .ELF.

So the next step where to make a simple executable, manage to link it to the libps2gdbStub.a (again, first time to link with a library) ensure it calls the gdb_stub_main.

The example makefile :

Code: Select all

EE_BIN = hello.elf
EE_OBJS = hello.o
EE_CFLAGS = -g

EE_INCS = -I$(PS2GDB)/ee
EE_LDFLAGS = -L$(PS2GDB)/lib
EE_LIBS = -lps2gdbStub -lps2ip -ldebug

all: $(EE_BIN)

clean:
	rm -f *.elf *.o

include $(PS2SDK)/samples/Makefile.pref
include $(PS2SDK)/samples/Makefile.eeglobal

Beginners should note that you must set an environment variable called PS2GDB pointing to the ps2gdb sources. Mine points to /usr/local/ps2dev/ps2gdb .
Also, please note that in the line :

Code: Select all

EE_LIBS =  -lps2gdbStub -lps2ip -ldebug

the -lps2gdbStub should be the first specified, otherwise it will not link! I just hate gcc and makefiles...

The example source (hello.c) :

Code: Select all

#include <stdio.h>

int gdb_stub_main&#40; int argc, char *argv&#91;&#93; &#41;;

int main&#40; int argc, char *argv&#91;&#93; &#41;
&#123;   
    int i=0;
    int j;

    printf&#40;"1\n"&#41;;
    j = gdb_stub_main&#40;argc, argv&#41;;
    printf&#40;"2\n"&#41;;

    while&#40;1&#41;
    &#123;
	    i++;
     &#125;
     return 0;
&#125;

So, after hitting make, just be sure to copy ps2ips.irx from the sdk to the project folder since it will be loaded when executing hello.elf.

Now I needed to use gdb at linux side, and configured to talk to mips32 target. Since on my ubuntu distro I didn't have the sources of gdb in order to rebuild it after issuing a ./configure I had to get those and do the ./configure step. After successful compiling, I've this after hitting ./gdb :

Code: Select all

GNU gdb 6.6
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "--host=i686-pc-linux-gnu --target=mips32".
Setting up the environment for debugging gdb.
No symbol table is loaded.  Use the "file" command.
No symbol table is loaded.  Use the "file" command.
/home/user/Desktop/gdb6.6/gdb-6.6/gdb/.gdbinit:8: Error in sourced command file:
No breakpoint number 0.
(gdb) 

Notice the "This GDB was configured as "--host=i686-pc-linux-gnu --target=mips32".".

OK, next step : copying the hello.c, hello.elf and ps2gdbStub.c into a folder and call gdb from there later.

I then executed hello.elf on the PS2 using ps2link and run gdb under linux at my laptop.

As megaman suggested, I typed "set endian little" and tell it to connect to my PS2's IP : "target remote 192.168.1.5:12" and got :

Code: Select all

(gdb) set endian little
The target endianness is set automatically (currently little endian)
(gdb) target remote 192.168.1.5:12
Remote debugging using 192.168.1.5:12
0x00000000 in ?? ()

I then load the hello example at the gdb using the file command :

Code: Select all

(gdb) file hello.elf
A program is being debugged already.
Are you sure you want to change the file? (y or n) y
Reading symbols from /home/user/Desktop/gdb6.6/gdb-6.6/gdb/hello.elf...done.

During symbol reading, invalid pointer size 4.

Here is the first problem I currently have : That warning info may explains why I cannot see the contents of the hello example program... But let's proceed.

Issuing a 'ni' and a 'step' command I get the info the execution is at line 1481 of ps2gdbStub.c - so actually, I needed to step out of ps2gdbStub.c in order to reach the hello sources.

Before doing that, we can inspect any variable at the scope : 'print thread_id_g' will show the contents of that variable of the gdbstub_init() function, so it seems gdb didn't have any problem getting the symbols for the ps2gdb library...

Code: Select all

(gdb) ni
1344    }
(gdb) step
gdbstub_init (argc=1088544, argv=0x185) at ps2gdbStub.c:1481
1481        return 0;
(gdb) print thread_id_g
$1 = 37
(gdb) step
1482    }
(gdb) step
gdb_stub_main (argc=1, argv=0xeac08) at ps2gdbStub.c:1518
1518       return 0;
(gdb) list
1513        if( gdbstub_init( argc, argv ) == -1 ) {
1514            gdbstub_error("INIT FAILED\n");
1515            ExitDeleteThread();
1516            return -1;
1517        }
1518       return 0;
1519    }
1520    
1521    ///
1522    //
(gdb) step 2
main (argc=1, argv=0xeac08) at hello.c:25
25        printf("2\n");
(gdb) list
20        int i=0;
21        int j;
22    
23        printf("1\n");
24        j = gdb_stub_main(argc, argv);
25        printf("2\n");
26    
27        while(1)
28        {
29            i++;
(gdb) print i
No symbol "i" in current context.
(gdb) print j
No symbol "j" in current context.

So has you can see above, it's possible to do normal gdb stuff like stepping through the source, get the listing, inspect variables and of course, set breakpoints (although I didn't above).

The only problem is that I cannot inspect any variable at the example hello... (what's the reason for the 'During symbol reading, invalid pointer size 4' warning?)

Anyone willing to help?

The patched ps2gdb sources are at :
http://www.mediafire.com/?v10mdv0h9gx

and the binaries I build for this example at:
http://www.mediafire.com/?iqqdimevx0n

[abdollaramadan]

Thanks very much, i haven't tried yet, and i don't know what's the problem, i'm too busy now, i may check it later, hopefully some one will help before me. :)

[cosmito]

About 3 weeks before posting at this thread I asked Mega Man about the problem I encountered and yesterday he replied :

(...)I think the optimizer removes the local variables. You should use more complicated code or disable the optimizer (-O0). This must be the last parameter with prefix "-O". Check the output of "make".
The gdbstub is not the best, because the support for 64 Bit and 128 Bit is removed. You may not be able to do everything.

Mega Man was right. Disabling the optimizer did the trick, so for the simple example it's then possible to inspect the contents of local variables 'i' and 'j'.

About the "During symbol reading, invalid pointer size 4" warning, I yet don't have a clue... Need to investigate more. But it seems not to be a problem (yet).

[cosmito]

Mega Man was right. Disabling the optimizer did the trick, so for the simple example it's then possible to inspect the contents of local variables 'i' and 'j'.

Obviously I should have read the gdb manual first:

Ninth Edition, for gdb version 6.8.50.20081018, page 86

Another possible effect of compiler optimizations is to optimize unused variables out of existence, or assign variables to registers (as opposed to memory addresses). Depending on the support for such cases offered by the debug info format used by the compiler, gdb might not be able to display values for such local variables. If that happens, gdb will print
a message like this:

No symbol "foo" in current context.

[cosmito]

In order to launch an ELF linked with ps2gdbStub I use ps2link v1.51 and then invoke gdb at linux side.

During a debugging session with a code written deliberately to cause an exception I was surprised to see the exception is not catched by the debugger but normally by the ps2link exception handler!

By looking at the ps2gdbStub source I see it seems to support exception handling and then I'm wondering if ps2link handling cannot be overloaded by ps2gdbStub's...

If so, how to execute the program to debug?

[Lukasz]

In order to launch an ELF linked with ps2gdbStub I use ps2link v1.51 and then invoke gdb at linux side.

During a debugging session with a code written deliberately to cause an exception I was surprised to see the exception is not catched by the debugger but normally by the ps2link exception handler!

By looking at the ps2gdbStub source I see it seems to support exception handling and then I'm wondering if ps2link handling cannot be overloaded by ps2gdbStub's...

If so, how to execute the program to debug?

I seem to recall there being a order/priority in which the exception handlers are called, ps2link exception handler being the first and ps2gdb the second. I believe the priority is the order in which the exception handlers are added, unless some non default value (probably zero) is passed as one of the parameters when adding the exception handler.

If this is not the case, you should be able to remove the ps2link exception handler in ps2gdb. Maybe ps2link already does this when it resets?

[cosmito]

So I fetched the ps2link sources from the repo planning to comment the exception handling section. After compiling the ps2link no longer catches the exception. To my surprise neither ps2gdb did!

Looking more carefully to ps2gdb sources (as I should have done in the first place) I saw two issues :

- The define TRAP_ALL_EXCEPTIONS must be, well, defined, at the ps2gdbStub.c. Otherwise only the break exception would be caught by it.
- Not all exceptions handled by ps2link are handled by ps2gdb... The offending code I used triggers a TLB store exception and to my bad luck, that wasn't handled by ps2gdb.

Two changes were required at ps2gdbStub.c :

- put the #define TRAP_ALL_EXCEPTIONS
- add support for the TLB store exception (code 3)

Code: Select all

static struct hard_trap_info
{
	unsigned char tt;		// Trap type code for MIPS R3xxx and R4xxx
	unsigned char signo;	// Signal that we map this trap into
} hard_trap_info[] = {
	{ 3, SIGBUS },			// TLB store.				// cosmito
	{ 4, SIGBUS },			// address error (load).
	{ 5, SIGBUS },			// address error (store).
	{ 6, SIGBUS },			// instruction bus error.
	{ 7, SIGBUS },			// data bus error.
	{ 9, SIGTRAP },			// break.
	{ 10, SIGILL },			// reserved instruction.
//	{ 11, SIGILL },			// CPU unusable.
	{ 12, SIGFPE },			// overflow.
	{ 13, SIGTRAP },		// trap.
	{ 14, SIGSEGV },		// virtual instruction cache coherency.
	{ 15, SIGFPE },			// floating point exception.
	{ 23, SIGSEGV },		// watch.
	{ 31, SIGSEGV },		// virtual data cache coherency.
	{ 0, 0}					// Must be last.
};

If anyone wants to add support for other exceptions, just refer to ps2link's excepHandler.c section :

Code: Select all

static char codeTxt[14][24] = 
{
    "Interrupt", "TLB modification", "TLB load/inst fetch", "TLB store",
    "Address load/inst fetch", "Address store", "Bus error (instr)", 
    "Bus error (data)", "Syscall", "Breakpoint", "Reserved instruction", 
    "Coprocessor unusable", "Arithmetic overflow", "Trap"
};

get the codes and add a line to ps2gdbStub.c for each (Interrupt = code 0, TLB modification = code 1, and so on)

With only the changes to ps2gdb, it's possible to use regular ps2link since ps2gdb actually steals the exception handling from it.