[Wine] Bash Script Shorcuts for Steam Games

[Martin Gregorie]

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