On Tue, 2011-09-27 at 10:34 -0500, SpawnHappyJake wrote: > I ran Portal and attached gdb to hl2.exe. Portal froze. I tried the > "c" for continuing hl2.exe in gdb in terminal, and this did unfreeze > Portal for a bit, but once I clicked "load" in Portal, the debugger > says it gets a segmentation fault, and Portal freezes. I quit gdb with > "q", and Portal unfreezes. > I would sort of expect that: debuggers are generally written in tandem with the compiler they expect to work with because they need a detailed understanding of the way the compiler emits code and its relationship to the source and, of course, the compiler's data storage allocation strategy. If the binary doesn't agree with its expectations or it doesn't understand the symbol table the compiler generated its can't do a lot, as you've seen. gdb expects to debug code generated the matching version of gcc just as the Visual C debugger works with the Visual C compiler and the Borland C compiler had its own debugger. I wouldn't expect any of these debuggers to work with executables from the other compilers. BTW, I should have added that IMO debuggers are getting increasingly obsolete. When computers were slow, even simple programs took minutes to compile a debugger was essential, and you were lucky to get one compilation run a day, debuggers were A Good Thing because using one was so much faster than recompiling the program. This us why a debugger can path the program on the fly and can often save the image so its rerunnable: in those days we used to patch bugs with the debugger so we could go on finding other bugs. At the end of the day you applied those changes to the source and stuck it in the queue for the overnight compilation run. Now that compilation of even quite large programs is almost instant, debugging with the aid of diagnostics such as Wine can output is very much faster. I haven't used a debugger since the last time I was working on a Tandem NonStop system back in the mid '90s. War story: a tape-based assembler I used while I was first learning to write assembler and we were all writing tiny 200 line programs and punching them on cards was so slow that you could grab your card deck from the output hopper, get the print-out from the printer, fix the errors with a hand punch and get the corrected cards back in the input hopper before the computer had finished compiling the equal sized programs written by the other 5 course members. This machine had 4 tape decks, card reader, line printer (no disks at all) and took 12 uS to do a half-word add, so its clock speed was around 0.08 MHz > Anyways, from my lay-man's perspective, I thought that, for example, > running a Windows program in WINE in terminal and getting that log was > "running a debugger" because you got lots of info about was was going > on, especially when a bug happens, thus is a "debugger." I thought gdb > would give something similar. But it looks like there is logging, and > there is debuging. And that some programs have features put in that > are accessed only by a debugger, even after compilation, is a new > insight to me - thanks, Martin. > Yep. Debugging is OK for really small programs, but its at far too fine-grained a level of detail for anything of any size and complexity: you spend forever messing about setting break points and finding that they're not really where you want them and repeating the exercise endlessly. Its much better to add display statements that report where the programs is at and shows you the interesting data at that point in a sensible format. You can even do better: throw the tracing output into a circular buffer and only display its contents when the program hits a problem and quits -this way you know why it quit (you do use sensible error messages, don't you?) but also get a backtrace showing what it had been doing before it stopped. No debugger can do that, especially if the program is one that normally runs continuously for days at at a time. > I went here: http://cs.baylor.edu/~donahoo/tools/gdb/tutorial.html, > and learned a few things. But the examples they give only work because > gdb has both the source code and the compiled program. > A debugger is remarkably useless if you don't have the current source in front of you - how else will you know where to put break points. > gdb -c [steam dump file] made gdb say that it wasn't a core dump file. > ... because it almost certainly doesn't contain either binary data or symbol tables output by the same version of gcc that your copy of gdb was compiled to work with. Martin
