4 ms·
I've spent the last seven years working on video game middleware and have had plenty of experience to many development environments. I've spent years developing
by maximilianburke 14y ago
I've spent the last seven years working on video game middleware and have had plenty of experience to many development environments. I've spent years developing for Windows, Linux, and Mac OS, and worked on every console that has been available on the market in that time.
GDB is different, but it's different in a bad way. Jonathan is completely correct in that it's a much worse experience because it doesn't easily give you the information you need to consume in order to find the problem you're looking to solve. Using the text user interface helps considerably but it still gets in the way. Sure, seeing source is fine, but what if you want disassembly too? Mixed source/assembly? Register view? Watches? Switching between threads easily? Viewing memory? DDD is an improvement but it still feels like it's 8 years behind. I'm glad to hear you're productive in that environment, most people (especially most game developers) aren't, and based on my experience getting people up to speed and fixing problems it's easier to get them going on Windows than on Linux.
That said, it's not the worst though. Green Hills takes that crown by a country mile.
The SN Systems debugger for PS3 is the best one I've used, bar none. It gives you all the data you need, is responsive, and has a few really nice features (write memory region to disk).
Not quite sure why you used gcc for PS3, SNC is far superior. It's faster at compiling and generates both faster and smaller code.
Both sed and grep are available for Windows and are definitely part of my toolkit. Visual Studio comes with an objdump substitute (dumpbin). Valgrind isn't available but DrMemory (http://code.google.com/p/drmemory/ http://code.google.com/p/drmemory/), Insure++/Purify (expensive, but useful), Very Sleepy (http://www.codersnotes.com/sleepy http://www.codersnotes.com/sleepy), CodeAnalyst (http://developer.amd.com/tools/heterogeneous-computing/amd-codeanalyst-performance-analyzer/ http://developer.amd.com/tools/heterogeneous-computing/amd-c...), VTune (http://software.intel.com/en-us/intel-vtune-amplifier-xe http://software.intel.com/en-us/intel-vtune-amplifier-xe), XPerf, and for video games especially, PIX, are all available.
- clhodapp 14y ago>Sure, seeing source is fine, but what if you want >disassembly too? Mixed source/assembly? Register view? >Watches? Switching between threads easily? Viewing memory? Disassembly: (gdb) layout asm Mixed source/assembly: (gdb) layout split Register view: (gdb) layout regs Watches: There is no window, which is too bad. You can say "display foo" and it will print the value of foo each time the execution breaks. You can also say just "display" and it will print the values of all variables you currently have set to display. Switching between threads: Say "info threads" to show all the threads in your application. Say "thread x" to switch to thread number x. Viewing memory: Again, there is no window, which is too bad. You can, however, use the "x" command, which is pretty full-featured and allows you to print the contents of a given-size chunk of memory, starting at a given point to the console in pretty much any format you might desire. You may already be aware of these features, but be discounting for some reason? Edit: Turns out, GDB also supports writing memory regions to disk: (gdb) dump binary memory <outfile> <startlocation> <stoplocation>