Wifi GDB Stub
Wifi GDB Stub
Hey guys,
First off - great work on the PSPSDK, everyone! It's been super cool to work with.
Since I'm basically too lazy and lacking in components/time/equipment to make a serial cable, I decided to take some time and try doing a GDB stub that uses the wifi. This was a bit complicated by the lack of a standard networking lib (I uses libpspnet from PSPRadio, the code's a bit rough but it works!) but I got something that works - you can connect with target remote foo:bar, and issue commands once in a breakpoint, etc.
However, the hex addresses I'm getting back seem to be very wrong (reversed?), callstack is crazy... All sorts of stuff. But the transport aspect itself seems to be working just fine; I can see in a network monitor that wellformed packets are going across the wire and getting processed on both ends.
In any case, I wanted to put this up for other eyes than myself to try out. www.coderhump.com/wifi_stub_patch.zip is the download; new files for sdk/debug and a new gdb example (had to muck with it a bit to get it to load the net libs properly). Compiling libpspnet and linking it in is just part of the fun. :)
I'd really like to make this into a robust way to debug a PSP. Even though it tends to monopolize the wifi hardware (though if you were in infrastructure mode it might be possible to let both the game and the debug stub operate, just on seperate hubs...), it's much easier to get started with than the serial port approach, and in many cases will work just as well...
So, from here, my goals are to figure out what's going on with the values I'm getting back from the debug stub, so that I can actually use this thing for my own projects. :)
I'd _LOVE_ any help or insight people might have to share! :)
Thanks,
Ben Garney
First off - great work on the PSPSDK, everyone! It's been super cool to work with.
Since I'm basically too lazy and lacking in components/time/equipment to make a serial cable, I decided to take some time and try doing a GDB stub that uses the wifi. This was a bit complicated by the lack of a standard networking lib (I uses libpspnet from PSPRadio, the code's a bit rough but it works!) but I got something that works - you can connect with target remote foo:bar, and issue commands once in a breakpoint, etc.
However, the hex addresses I'm getting back seem to be very wrong (reversed?), callstack is crazy... All sorts of stuff. But the transport aspect itself seems to be working just fine; I can see in a network monitor that wellformed packets are going across the wire and getting processed on both ends.
In any case, I wanted to put this up for other eyes than myself to try out. www.coderhump.com/wifi_stub_patch.zip is the download; new files for sdk/debug and a new gdb example (had to muck with it a bit to get it to load the net libs properly). Compiling libpspnet and linking it in is just part of the fun. :)
I'd really like to make this into a robust way to debug a PSP. Even though it tends to monopolize the wifi hardware (though if you were in infrastructure mode it might be possible to let both the game and the debug stub operate, just on seperate hubs...), it's much easier to get started with than the serial port approach, and in many cases will work just as well...
So, from here, my goals are to figure out what's going on with the values I'm getting back from the debug stub, so that I can actually use this thing for my own projects. :)
I'd _LOVE_ any help or insight people might have to share! :)
Thanks,
Ben Garney
Re: Wifi GDB Stub
Just wanted to make sure credit is given to the right people. libpspnet in PSPRadio is based on psppet's wifi example code. All I really did was integrate it with the NetBSD socket related header files.. (BTW, thanks psppet!! :) )
Cool stuff you're doing, though! If you get it to work, it would help a lot of developers! I'd love to be able to use gdb/insight!
Thanks!!
Raf.
Cool stuff you're doing, though! If you get it to work, it would help a lot of developers! I'd love to be able to use gdb/insight!
Thanks!!
Raf.
PSPPet is a stud - very impressive work he's done!
Anybody have GDB experience to be able to debug this behavior? I'm hoping it's fairly trivial; I'm trying to port a much larger application and having a working debugger would be _invaluable_. I'll poke at it myself of course but any way to short circuit the process would be very welcome.
Anybody have GDB experience to be able to debug this behavior? I'm hoping it's fairly trivial; I'm trying to port a much larger application and having a working debugger would be _invaluable_. I'll poke at it myself of course but any way to short circuit the process would be very welcome.
I haven't had a chance to focus in on it. The wifi/net part works great, but the stub is giving me weird stuff, so I guess my next step is going to be to dig into that. Hopefully sometime in the next few days - have to give some other projects love at the moment but ought to have time soon.
I'd love to hook up with someone who knew GDB/PSP debugging internals well and really knock down all the problems! Anybody out there? :)
Ben
I'd love to hook up with someone who knew GDB/PSP debugging internals well and really knock down all the problems! Anybody out there? :)
Ben
Done a little more experimenting.
I seem to be experiencing similar problems to <http://sources.redhat.com/ml/ecos-discu ... 00337.html>. But not sure how to map the suggested fixes to the PSP GDB build; tried using the build options but with no luck, still get messed up addresses. Witness a reported callstack:
And it read the disassembly there successfully from the remote device, witness the packet log!
So, here's what I'm getting over the wire vs. what is showing up in GDB:
And the PC register according to GDB:
Hmmm...
So, I have this feeling there's something just ever so slightly off here, but I can't pin it down. :-/ Anyone have any thoughts?
Ben
I seem to be experiencing similar problems to <http://sources.redhat.com/ml/ecos-discu ... 00337.html>. But not sure how to map the suggested fixes to the PSP GDB build; tried using the build options but with no luck, still get messed up addresses. Witness a reported callstack:
Code: Select all
(gdb) bt
#0 0xffffffff889005d4 in ?? ()
#1 0xffffffff889005d4 in ?? ()
Previous frame identical to this frame (corrupt stack?)
(gdb) disassemble 0x89005d4
Dump of assembler code for function pspDebugBreakpoint:
0x089005d4 <pspDebugBreakpoint+0>: break
0x089005d8 <pspDebugBreakpoint+4>: jr ra
0x089005dc <pspDebugBreakpoint+8>: nop
End of assembler dump.
(gdb)
Code: Select all
Sending packet: $m89005d4,4#6b...Ack
Packet received: 0d000000
Sending packet: $m89005d8,4#6f...Ack
Packet received: 0800e003
Sending packet: $m89005dc,4#9a...Ack
Packet received: 00000000
Code: Select all
Sending packet: $c#63...Ack
Packet received: T0525:d4059088;1e:58992e88;1d:58992e88;
Program received signal SIGTRAP, Trace/breakpoint trap.
0xffffffff889005d4 in ?? ()
Code: Select all
pc
889005d4
So, I have this feeling there's something just ever so slightly off here, but I can't pin it down. :-/ Anyone have any thoughts?
Ben
From http://forums.ps2dev.org/viewtopic.php?t=3435:
It looks to me like you're running your main thread in kernel mode, and the sign-extension on the pc is just a side-effect of that.The most important thing to note is your module must start in kernel mode, but you app should only be in user mode
Thank you so much for taking a look!
I had no idea that that would be a related issue. Bizarre. What are the other implications of running the main thread in kmode?
I believe I need to be in a kernel mode thread to properly load the networking libraries. But everything after that can/should be in user mode. So I guess my best bet is to load libs from a kernel thread, then immediately kick off my "real" code in a user thread. That way I can avoid ever having to run in kmode at all...
I'll have to try this out tonight, thank you for the advice!
I had no idea that that would be a related issue. Bizarre. What are the other implications of running the main thread in kmode?
I believe I need to be in a kernel mode thread to properly load the networking libraries. But everything after that can/should be in user mode. So I guess my best bet is to load libs from a kernel thread, then immediately kick off my "real" code in a user thread. That way I can avoid ever having to run in kmode at all...
I'll have to try this out tonight, thank you for the advice!
Set up the app to run in USERMODE, but add anbengarney wrote:Thank you so much for taking a look!
I had no idea that that would be a related issue. Bizarre. What are the other implications of running the main thread in kmode?
I believe I need to be in a kernel mode thread to properly load the networking libraries. But everything after that can/should be in user mode. So I guess my best bet is to load libs from a kernel thread, then immediately kick off my "real" code in a user thread. That way I can avoid ever having to run in kmode at all...
I'll have to try this out tonight, thank you for the advice!
__attribute__ ((constructor))
void loaderInit()
{}
function that starts a kernel thread, which starts the network drivers.
That's what I'm doing in PSPRadio now, and it works fine.
(You will also need to make sure to call FlushCaches() inside nlhLoadDrivers() and not in nlhInit()).
Raf.
(DHCP will also work if you do it this way; see this topic:
http://forums.ps2dev.org/viewtopic.php?t=3877)
Howdy gentlemen,
Success! Between raf's insight into networking and jim's point about kernel mode vs user mode debugging, I got the debugger to wiggle. Brought up a modified version of the GDB example, hit circle, got an exception in psp-gdb. Made sw_ return, and continued execution. Hit cross and hit the break.
Ran into some troubles there getting it to resume - told it to step and it just sat there. Packet log indicates it's doing a lot of something, but apparently not enough to keep going - I wonder if it's just veeery slooowly stepping over the network link, or it could be it's trying to re-exec the break op over and over?
I also have a feeling I'm sending stuff over the wire one character per TCP packet, which is mind numbingly slow. I'll have to spend some time with ethereal and figure that one out; it might explain a few things like the stepping. :)
But the tool is now useful - even if it's a bit brittle, a call stack and the ability to snag some variable state is a LOT better than debugging with printf's.
So, I'm going to spend some time cleaning things up (right now the code is NOT pretty, and I broke stdio capturing), then I'll post what I've got so y'all can make use of it and hopefully help improve it, too. :)
Thanks for all the help!
Ben
Success! Between raf's insight into networking and jim's point about kernel mode vs user mode debugging, I got the debugger to wiggle. Brought up a modified version of the GDB example, hit circle, got an exception in psp-gdb. Made sw_ return, and continued execution. Hit cross and hit the break.
Ran into some troubles there getting it to resume - told it to step and it just sat there. Packet log indicates it's doing a lot of something, but apparently not enough to keep going - I wonder if it's just veeery slooowly stepping over the network link, or it could be it's trying to re-exec the break op over and over?
I also have a feeling I'm sending stuff over the wire one character per TCP packet, which is mind numbingly slow. I'll have to spend some time with ethereal and figure that one out; it might explain a few things like the stepping. :)
But the tool is now useful - even if it's a bit brittle, a call stack and the ability to snag some variable state is a LOT better than debugging with printf's.
So, I'm going to spend some time cleaning things up (right now the code is NOT pretty, and I broke stdio capturing), then I'll post what I've got so y'all can make use of it and hopefully help improve it, too. :)
Thanks for all the help!
Ben
-
- Posts: 339
- Joined: Thu Sep 29, 2005 4:19 pm
Guide to using WLAN-GDB.
Updated the archive: http://www.coderhump.com/wifi_stub_patch.zip
Howdy, got my time. :)
Cleaned things up. There's a little bit of debug spam but it's largely informative rather than annoying. :)
So here's an overview of what I've done. It's clean enough for my needs but I'd love to make it more streamlined to use, find a good way to package it for the community to use.
You need libpspnet from PSPRadio in your include & lib path. This conflicts with the net stuff in pspsdk currently; I imagine that in the future this will be cleaned up. :) For now, I just got rid of the pspsdk files and used libpspnet exclusively.
Next, you need the GDB stub files from my archive. They're modified to use network instead of serial. Drop them in the sdk debug directory, overwriting the current files of the same names. make && make install so you're linking against the right libs in later steps.
Now open your code; here are the relevant bits you need to include to debug with GDB over wifi! :)
(Note: you may want to configure your PSP to use a static IP, so that you can connect to it more easily...)
Make sure your module defs look like this:
Put this somewhere in your code:
And then at the start of your main(), add this:
Ok, all set! You might have to add -lpspgdb -lpspgdb_user -lpspnet to your libs in your project settings.
Includes you probably need:
Some comments:
Like my cheezy semaphore? :) Something to be cleaned up. The thread wait function doesn't seem to wait properly, so I hacked that in.
The code could be better contained; for instance, the loader stuff could probably be in the lib code, and the thread wait code could be in a function as well, reducing the impact on client code significantly.
But that's what I got and tomorrow (with luck) I'll be instrumenting my own project with this code. :)
(I did this, and it finally works... I apparently cut & pasted wrong, wasting several hours of time, ick.)
Bring up your code normally via gdb, then type:
to start debugging.
Feedback supremely welcome!
Thanks,
Ben
Update:
Noted some includes you need.
Noted how to use GDB, briefly.
Howdy, got my time. :)
Cleaned things up. There's a little bit of debug spam but it's largely informative rather than annoying. :)
So here's an overview of what I've done. It's clean enough for my needs but I'd love to make it more streamlined to use, find a good way to package it for the community to use.
You need libpspnet from PSPRadio in your include & lib path. This conflicts with the net stuff in pspsdk currently; I imagine that in the future this will be cleaned up. :) For now, I just got rid of the pspsdk files and used libpspnet exclusively.
Next, you need the GDB stub files from my archive. They're modified to use network instead of serial. Drop them in the sdk debug directory, overwriting the current files of the same names. make && make install so you're linking against the right libs in later steps.
Now open your code; here are the relevant bits you need to include to debug with GDB over wifi! :)
(Note: you may want to configure your PSP to use a static IP, so that you can connect to it more easily...)
Make sure your module defs look like this:
Code: Select all
PSP_MODULE_INFO("EXTEST", 0x1000, 1, 1);
PSP_MAIN_THREAD_ATTR(PSP_THREAD_ATTR_USER); // <-- this is the really important bit.
Code: Select all
volatile int stupidThreadThing = 0;
int DriverThread(SceSize args, void *argp)
{
pspDebugScreenPrintf("Initialising net drivers...\n");
nlhLoadDrivers(&module_info);
pspDebugScreenPrintf("Initialising GDB stub...\n");
pspDebugGdbStubInit();
pspDebugScreenPrintf("Done.\n");
stupidThreadThing = 1;
sceKernelSleepThreadCB();
return 0;
}
/* Initialise net and GDB */
int debugInitThread = 0;
__attribute__((constructor))
void loaderInit()
{
pspDebugScreenInit();
pspDebugScreenPrintf("Alive...\n");
pspKernelSetKernelPC();
debugInitThread = sceKernelCreateThread("driverloader_thread", DriverThread, 0x11, 0xFA0, 0, 0);
if (debugInitThread >= 0)
sceKernelStartThread(debugInitThread, 0, 0);
pspDebugScreenPrintf("Thread started...\n");
}
Code: Select all
while(!stupidThreadThing)
sceKernelDelayThread(5000000);
sceKernelWaitThreadEnd(debugInitThread, NULL);
Includes you probably need:
Code: Select all
#include <pspnet.h>
#include <pspdebug.h>
Like my cheezy semaphore? :) Something to be cleaned up. The thread wait function doesn't seem to wait properly, so I hacked that in.
The code could be better contained; for instance, the loader stuff could probably be in the lib code, and the thread wait code could be in a function as well, reducing the impact on client code significantly.
But that's what I got and tomorrow (with luck) I'll be instrumenting my own project with this code. :)
(I did this, and it finally works... I apparently cut & pasted wrong, wasting several hours of time, ick.)
Bring up your code normally via gdb, then type:
Code: Select all
target remote <yourip>:23
Feedback supremely welcome!
Thanks,
Ben
Update:
Noted some includes you need.
Noted how to use GDB, briefly.
Last edited by bengarney on Sat Oct 29, 2005 5:20 pm, edited 3 times in total.
Re: Guide to using WLAN-GDB.
Cool, thanks! I'm gonna try it now..
I'll let you know how it goes...
PS: Just noticed that Makefile.am needs to be updated to include:
-I$(top_srcdir)/../../PSP/SharedLib/libpspnet \
-I$(top_srcdir)/sdk/utility
(Of course libpspnet needs to be tailored to your installation; but sdk/utility needs to be added as well.)
Raf
I'll let you know how it goes...
PS: Just noticed that Makefile.am needs to be updated to include:
-I$(top_srcdir)/../../PSP/SharedLib/libpspnet \
-I$(top_srcdir)/sdk/utility
(Of course libpspnet needs to be tailored to your installation; but sdk/utility needs to be added as well.)
Raf
Re: Guide to using WLAN-GDB.
I had to change
As profiles start from 1, not 0, in gdb-userlib.c.
I still haven't played much with it for lack of time; but seems to work, so far!, good job!
Thanks,
Raf.
Code: Select all
err = sceNetApctlConnect(0);
to
err = sceNetApctlConnect(1);
I still haven't played much with it for lack of time; but seems to work, so far!, good job!
Thanks,
Raf.