Q:

How do debuggers help one with finding information about how a program does something?

Let's say I want to reverse engineer an executable that interprets some data type. I want to see how the program interferes with the file, and what is stored. In the case that decompilation is not an option, I have disassembly and debugging left. With disassembly, I would have to look into 200,000 lines of assembly, which would be rather tedious, especially if I needed to hand code it back.
From my experience with debugging with gdb, all that I was able to do is see when a thread is being created, and inspecting the stack, both of which don't seem like very useful to me.
Is my approach to debugging incorrect? If it is, then what can you do with a debugger like gdb, avoiding paid debuggers or software, to find out a piece of information similar to the one I am trying to find? Can someone give me a pointer for the sake of orientation?

A:

99% of RE is figuring out what not to RE.  
Assuming there are 200k lines of assembly - using a debugger can quickly narrow that down to a few thousand that are actually processing the data you're interested in. Try setting a breakpoint on syscalls like open() or read() to see when it's interacting with your file, and following the buffer that the data is read in to.  
Once you locate where your data is coming in to the program, static analysis becomes a much less daunting task.

