PSP GDB

[TyRaNiD]

For lack of a better place to put it. For those who haven't noticed there is now a gdb stub in PSPSDK to allow you to do rudementary debugging over the remote serial interface. Just for info this is abit of info on how to set it up and use it.

Firstly if you haven't built one already I would highly recommend building a serial cable if you are serious about doing pspdev, Nil's description of how to build it is at http://nil.rpc1.org/psp/remote.html. At the least it allows you to add a serial tty so you can finally print debug statements without screwing up your display.

Next you will need to build a targetted version of gdb. I have placed a patch in psptoolchain (in svn) so you can build gdb along with the rest of the toolchain. If I can be bothered I might put out my patch for insight (which is gdb + gui) but I think that only works in X window environments. You might be able to use another frontend to gdb such as ddd or kdbg but personally I haven't had much success.

The gdb stub is actually a user mode handler (not exception mode), it will run in the context of the thread which either had a breakpoint set or crashed. The stub itself must be compiled into the executable and a method to enter the debugger should be set. Refer to the gdb sample in pspsdk for a skeleton to setting up gdb in your app. The most important thing to note is your module must start in kernel mode, but you app should only be in user mode. This is a limitation of the elfs not of gdb itself.

And as for actually using it, build the sample (or your app) and psp-gdb myapp.elf to start gdb with your application symbols. Use "set remotebaud" to set the serial baud rate if you need to (the sample defaults to 38400) then when your app has loaded and trapped itself then type "target remote /dev/ttyS0" to connect to it. Obviously replace /dev/ttyS0 with your serial port. You should now have control over the program and can play around with it's data, set new breakpoints etc.

That is all.

[Oobles]

Nice work TyRaNiD. In regards to the insight patch. I've used insight on cygwin before and it runs fine, so would be useful for a lot of people.

David aka Oobles.

[mrbrown]

Stickied.

Great work, Tyranid. Is the PSP serial cable easier or more difficult to build than the PS2 serial cable?

Have you tried doing a kernel mode stub? :)

[TyRaNiD]

The PSP serial cable is easier than the ps2 if only because you dont have to open it up and solder onto the main board, it does depend somewhat if you go for butchering an existing cable of building the connector yourself mind.

As for a kernel mode stub (in the sense of an exception mode stub) there is seemingly the problem of some sort of watchdog shutting down the psp if you stay in an exception too long. Until I find out how to disable that (if even possible) then a non-exception mode stub is the only thing possible.

[Oobles]

Another thought regarding the GUI front end for gdb. You might want to try eclipse. A quick google found this.

http://eclipsewiki.editme.com/MipsPlatformDebug

I've been using the C/C++ development environment for debugging some native cygwin based applications and it is a very nice environment to work with. Can't see why it wouldn't work with the PSP.

David. aka Oobles.

[holger]

As for a kernel mode stub (in the sense of an exception mode stub) there is seemingly the problem of some sort of watchdog shutting down the psp if you stay in an exception too long. Until I find out how to disable that (if even possible) then a non-exception mode stub is the only thing possible.

You could fork a new user-mode process that does the actual communication, clear the exception and modify the code of the faulted process so that it spins in a busy-loop while gdb is connecting.

btw: is there any reason that you did not used the wlan interface?

[ooPo]

From the remote link originally posted: http://nil.rpc1.org/psp/remote.html

The remote is a very optional device for the PSP => it can be used for other purposes (eg. debug) without interfering with standard operations (USB, WiFi, ...)

Useful for debugging without being too invasive.

[Shine]

Firstly if you haven't built one already I would highly recommend building a serial cable if you are serious about doing pspdev, Nil's description of how to build it is at http://nil.rpc1.org/psp/remote.html. At the least it allows you to add a serial tty so you can finally print debug statements without screwing up your display.

A serial port could be useful for many things, like interfacing external hardware. I don't have a MAX3232, but I've found a MAX232 in my homebrew electronics parts box, which works for a test setup.

I think I'll add the serial port support to Lua Player, too. Imagine what you can do with a Lua script, which controls a RC car with an external microcontroller and some sensor feedbacks. Or you can control a model railway installation, with a fancy railway control center on your PSP display :-)

But for this it would be nice to use the port as standard stdout and stdin. I've changed your SIO sample, now it works from user mode thread and with stdout, and added some more documentation:

http://www.luaplayer.org/sio/readme.html
http://www.luaplayer.org/sio.zip (compiled EBOOT.PBP for 1.00 and 1.50 firmwares included)

but stdin doesn't work, I don't know why. Opening "tty0:" works, so stdin should work, too. Looks like a problem in the libc part of the PSPSDK.

[TyRaNiD]

Indeed probably my primary reason for choosing serial instead of wireless is it is less intrusive, a poor excuse but one none the less :P Plus it is bad enough waiting for the power to come up on the serial port but at least on my setup the association time to make a wlan connection is just truely truely painful.

Of course because it is a usermode and not exception mode then you should be able to implement a wlan version. Just take gdb-kernellib.c and implement your own wlan version to read and write characters to the wlan interface. You might also need to change one thing in gdb-stub.c itself but it isn't required for actually running on wlan, it just means you would loose tty output :P

You could fork a new user-mode process that does the actual communication, clear the exception and modify the code of the faulted process so that it spins in a busy-loop while gdb is connecting.

Well the way it is designed it kind of does this already, I hijack the current thread to run my gdb stub in. Originally I was going to have a separate kernel mode thread which was signalled from the exceptioned thread but that has permission problems. The trouble comes due to a lack of knowledge of the internals of the psp threading system. Ideally gdb-stub would only work in exception mode and it would directly hook into the thread manager to switch thread contexts on the fly, but something like that will probably never happen :P

[0x0001]

is this libgdb?

does this gdb port support
opengl 2.0 specs ?
does psp support opengl 2.0?
or is it more opengl | es or
other

any info is greatly
appreciated as im
currently working on my own
serial connect cable atm :)

ps. which is best chip to use
for serial ? ....price is no option
im looking for highest quality
of manufacturing

[TyRaNiD]

For info I have committed my patchers for the insight debugger to svn for people who just have to use a GUI :P

[florinsasu]

The trouble comes due to a lack of knowledge of the internals of the psp threading system. Ideally gdb-stub would only work in exception mode and it would directly hook into the thread manager to switch thread contexts on the fly, but something like that will probably never happen :P

maybe it would be interesting some info i gathered about thread system. internaly, the kernel keeps a list of TCBs. actualy there is a whole hierarchy of objects and meta-objects that holds info about threads, modules, memory allocation, semaphores, etc.

the structure of such an object is:

Code: Select all

typedef struct tag_OBJECT {
	struct tag_OBJECT	*next, *prev, *parent;//+00
	u32				objectId;	           //+0C
	char				*name;			  //+10
	u8				unk1;			    //+14
	u8				size;			     //+15
	u16				unk2;			   //+16
	u32				unk3;		           //+18
} OBJECT;                                     //=1C

you can walk the list with next and prev. parent is a Meta<object>, in case of threads it is called "MetaThread".
size is the number of 4-byte words that compose the header, usualy 7. this is just the header common for all objects. in case of threads size is 12. following the 0x30 bytes of thread object header you can find its TCB. it has the following structure:

Code: Select all

typedef struct tag_TCB{
	void	*link1, *link2;	//+00
	u32		thid;			//+08
	u32		status;			//+0C
	u32		currentPriority;//+10
	u32		wakeupCount;	//+14
	u32		exitStatus;		//+18
	u32		waitType;		//+1C
	void	*waitObject;	//+20
	u32		unk1[10];		//+24
	void	*cb_next;		//+4C
	void	*cb_prev;		//+50
	u32		unk2[3];		//+54
	u32		initPriority;	//+60
	u32		runClocks_lo;	//+64
	u32		runClocks_hi;	//+68
	u32		entry;			//+6C
	u32		kstack;			//+70
	u32		kstacksize;		//+74
	u32		sp;				//+78
	u32		stack;			//+7C
	u32		stacksize;		//+80
	u32		unk3;			//+84
	u32		gpReg;			//+88
	u32		unk4;			//+8C
	void	*klts;			//+90
	u32		unk5[15];		//+94
	u32		attribute;		//+D0
	u32		attribute_;		//+D4
	u32		argSize;		//+D8
	void	*argBlock;		//+DC
	u32		unk6[2];		//+E0
	u32		initPreemptCount;//+E8
	u32		threadPreemptCount;//+EC
	u32		releaseCount;	//+F0
	CONTEXT	*context;		//+F4
	u32		unk7;			//+F8
	void	*vfpu_context;	//+FC
} TCB;

vfpu_context pointer is valid only if attribute field has 0x4000 flag and is an array of 128+16 32-bit values. a CONTEXT block looks like this:

Code: Select all

typedef struct tag_CONTEXT{
	u32	type;				//+000
	u32	gpr[31];			//+004
	u32	fpr[32];			//+080
	u32	fc31;				//+100
	u32	hi;					//+104
	u32	lo;					//+108
	u32	SR;					//+10C
	u32	EPC;				//+110
	u32	field_114;			//+114
	u32	field_118;			//+118
} CONTEXT;

so you can walk the threads list like this:

Code: Select all

PspIntrHandlerOptionParam intrinfo;
intrinfo.size = sizeof(intrinfo);
QueryIntrHandlerInfo(0x13, -1, &intrinfo);//0x13 == PSP_THREAD0_INT
OBJECT *p, *thread = (OBJECT*)(*(u32*)intrinfo.common - 0x30);
for (p=thread; p != thread->next; p=p->prev)
	if (p->thid == aThreadID)
		break;
TCB *tcb = (TCB*)((u32)p + 0x30);//0x30 == p->size * sizeof(u32)

ie. from the common of thread interrupt you get the tcb address of current running thread

[jimparis]

$at and $v1 appear to get clobbered while stepping with gdb. This is with the gdb sample:

Code: Select all

Remote debugging using /dev/ttyS0
main () at main.c:81
81              sceCtrlSetSamplingCycle(0);
(gdb) info reg
          zero       at       v0       v1       a0       a1       a2       a3
 R0   00000000 0008ff00 044ba167 00000000 00000001 00000000 88226030 00000000 
            t0       t1       t2       t3       t4       t5       t6       t7
 R8   00000000 00000000 20008600 882ffa00 09ffee08 00000e00 08900434 00008600 
            s0       s1       s2       s3       s4       s5       s6       s7
 R16  09ffeefc 09ffee34 00000001 0000001c 09ffeee0 00000013 deadbeef deadbeef 
            t8       t9       k0       k1       gp       sp       s8       ra
 R24  00000000 88225e28 09ffef00 00000000 0890fe80 09ffee18 09ffee18 08900500 
            sr       lo       hi      bad    cause       pc
      20008613 deadbeef deadbeef 15c01008 00000024 08900500 
           fsr      fir
      00000e00 00003351 
(gdb) stepi
0x08900504      81              sceCtrlSetSamplingCycle(0);
(gdb) info reg
          zero       at       v0       v1       a0       a1       a2       a3
 R0   00000000 00000000 044ba167 20008613 00000000 00000000 88226030 00000000 
            t0       t1       t2       t3       t4       t5       t6       t7
 R8   00000000 00000000 20008600 882ffa00 09ffee08 00000e00 08900434 00008600 
            s0       s1       s2       s3       s4       s5       s6       s7
 R16  09ffeefc 09ffee34 00000001 0000001c 09ffeee0 00000013 deadbeef deadbeef 
            t8       t9       k0       k1       gp       sp       s8       ra
 R24  00000000 88225e28 09ffef00 00000000 0890fe80 09ffee18 09ffee18 08900500 
            sr       lo       hi      bad    cause       pc
      20008613 deadbeef deadbeef 15c01008 00000024 08900504 
           fsr      fir
      00000e00 00003351 

The instruction stepped over is "mov a0, zero". $v1 is left in $at and $sr is left in $v1.

[jimparis]

Nevermind, I fixed it in rev 1150.

[terryxq]

I can not access this url, http://nil.rpc1.org/psp/remote.html
could anyone send the content of that page by mail?

thanks, my email is [email protected]

[florinsasu]

some info for low-level devs:
http://ps2dev.ps2-scene.org/COP0_CONTROL.txt is the list of the COP0 Control registers and how they are used :)

[mrbrown]

You're missing $22.

[florinsasu]

You're missing $22.

what is in $22? who sets/uses it

[ultra]

hi,

i tried this yesterday... and works fine... good job... even with a max 233 which is suppossed to run on 5v ;)


thx...
ultra

[kohntarkosz]

hi,

My laptop PC has no serial port. Moreover, even though a rs232 / remote adapter isn't impossible to make, it's not trivial for everyone.

Hence the question : would it be possible to add infrared (irda) support ?

thanks.