| View previous topic :: View next topic |
| Author |
Message |
TyRaNiD
Joined: 18 Jan 2004
Posts: 918
|
 Posted: Tue Sep 20, 2005 7:32 am Post subject: PSP GDB |
 |
|
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. |
|
| Back to top |
|
 |
Oobles
Site Admin
Joined: 17 Jan 2004
Posts: 362
Location: Melbourne, Australia
|
| Posted: Tue Sep 20, 2005 10:51 am Post subject: |
|
|
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. |
|
| Back to top |
|
|
mrbrown
Joined: 17 Jan 2004
Posts: 1536
|
| Posted: Tue Sep 20, 2005 2:48 pm Post subject: |
|
|
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? :) |
|
| Back to top |
|
|
TyRaNiD
Joined: 18 Jan 2004
Posts: 918
|
| Posted: Tue Sep 20, 2005 3:21 pm Post subject: |
|
|
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. |
|
| Back to top |
|
|
Oobles
Site Admin
Joined: 17 Jan 2004
Posts: 362
Location: Melbourne, Australia
|
| Posted: Tue Sep 20, 2005 3:31 pm Post subject: |
|
|
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. |
|
| Back to top |
|
|
holger
Joined: 18 Aug 2005
Posts: 204
|
| Posted: Tue Sep 20, 2005 5:34 pm Post subject: |
|
|
| TyRaNiD wrote: | | 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? |
|
| Back to top |
|
|
ooPo
Site Admin
Joined: 17 Jan 2004
Posts: 2032
Location: Canada
|
| Posted: Tue Sep 20, 2005 10:55 pm Post subject: |
|
|
From the remote link originally posted: http://nil.rpc1.org/psp/remote.html
| Quote: | | 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. |
|
| Back to top |
|
|
Shine
Joined: 03 Dec 2004
Posts: 728
Location: Germany
|
| Posted: Wed Sep 21, 2005 5:52 am Post subject: Re: PSP GDB |
|
|
| TyRaNiD wrote: | 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. |
|
| Back to top |
|
|
TyRaNiD
Joined: 18 Jan 2004
Posts: 918
|
| Posted: Wed Sep 21, 2005 6:05 am Post subject: |
|
|
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
| Quote: | 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 |
|
| Back to top |
|
|
0x0001
Joined: 21 Jul 2005
Posts: 11
|
| Posted: Wed Sep 21, 2005 8:48 am Post subject: |
|
|
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 |
|
| Back to top |
|
|
TyRaNiD
Joined: 18 Jan 2004
Posts: 918
|
| Posted: Tue Sep 27, 2005 3:05 am Post subject: |
|
|
| For info I have committed my patchers for the insight debugger to svn for people who just have to use a GUI :P |
|
| Back to top |
|
|
florinsasu
Joined: 15 Dec 2004
Posts: 47
|
| Posted: Wed Sep 28, 2005 7:16 am Post subject: |
|
|
| TyRaNiD wrote: | | 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: | 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: | 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: | 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: | 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 |
|
| Back to top |
|
|
jimparis
Joined: 10 Jun 2005
Posts: 1179
Location: Boston
|
| Posted: Thu Oct 13, 2005 4:06 pm Post subject: |
|
|
$at and $v1 appear to get clobbered while stepping with gdb. This is with the gdb sample:
| Code: |
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. |
|
| Back to top |
|
|
jimparis
Joined: 10 Jun 2005
Posts: 1179
Location: Boston
|
| Posted: Thu Oct 13, 2005 4:31 pm Post subject: |
|
|
| Nevermind, I fixed it in rev 1150. |
|
| Back to top |
|
|
terryxq
Joined: 12 Oct 2005
Posts: 16
|
|
| Back to top |
|
|
florinsasu
Joined: 15 Dec 2004
Posts: 47
|
|
| Back to top |
|
|
mrbrown
Joined: 17 Jan 2004
Posts: 1536
|
| Posted: Wed Oct 26, 2005 3:42 pm Post subject: |
|
|
| You're missing $22. |
|
| Back to top |
|
|
florinsasu
Joined: 15 Dec 2004
Posts: 47
|
| Posted: Wed Oct 26, 2005 8:21 pm Post subject: |
|
|
| mrbrown wrote: | | You're missing $22. |
what is in $22? who sets/uses it |
|
| Back to top |
|
|
ultra
Joined: 26 Jan 2006
Posts: 1
Location: kiel
|
| Posted: Thu Jan 26, 2006 2:47 pm Post subject: |
|
|
hi,
i tried this yesterday... and works fine... good job... even with a max 233 which is suppossed to run on 5v ;)
thx...
ultra |
|
| Back to top |
|
|
kohntarkosz
Joined: 24 Jan 2006
Posts: 3
Location: Paris, France
|
| Posted: Fri Jan 27, 2006 1:29 am Post subject: |
|
|
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. |
|
| Back to top |
|
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
