 |
 |
Date: Fri, 18 Mar 2005 11:03:24 -0500 From: Aleksandar Donev <[log in to unmask]> Most compilers offer a switch to enable tracing the location of an error (say -gline. -traceback, --trace, etc.) and also -g to put debugging info. What exactly is the difference? I presume -g puts in a lot more info, and -gline just puts line numbers on procedure calls? Is it expected that either one will significantly affect performance (without -O0, but rather high optimizations)? Most compilers or most fortran compilers? I'm unfamiliar with these the tracing options to the compiler, but I can give you some general information. Getting tracebacks requires the ability to capture enough context about a procedure and then be able to "unwind" to previous procedures. This context typically includes the program counter and stack pointer, and depending on the architecture it could be many other registers. Modern systems often have libraries to assist in some of this. Debuggers sometimes use them, and sometimes write their own. The unwind mechanism often requires tables, typically indexed by procedure, saying what it does with the registers so the unwinder can undo it and "virtually return" to the caller. I suspect -traceback and --trace ensure these tables exist for the unwinding mechanism being used. Note that C++'s exception system demands sufficient tables for all procedures so it can accomplish catch/throw. From it's name, -gline is something different. If you have a PC (program counter), you probably want to know what procedure it is in. That's a relatively simple PCRange->procedureDescriptor table, also needed by the unwinder. If you want line number information, you also need <procDesc,offset> to <sourceFile,lineNum> tables. I suspect -gline makes sure these exist, perhaps just for an external debugger, or perhaps so that the program can see it introspectively. -g traditionally means "include debugging information" and by this it is more than just line numbers, but also the names of variables, where they are (memory, stack, register), what type they are (complex*8, type(tree)), what their lifetime is, arguments to procedures, etc, etc. Things that make 'print <expr>' work; and other things, too. You can unwind and get line numbers without all the argument and variable information that -g provides, and -g often triples (or more) the size of the executable due to the debug tables. There has always been a tension between optimization and debugging information. Traditionally, -g by itself turns off optimization. A common effect of this is that each source line's instructions are scheduled not to overlap with another line's instructions. No CSE collapsing, no loop hoisting, nothing, because that would cause the line number to jump around as the PC advanced, which makes the 'step' and 'next' operations do unhelpful things. When you start to increase the optimization level, it is still possible to retain some debugging information, but the quality starts to drop, the utility starts to drop, and at very high levels the compiler vendor may not try very hard to preserve debug info. One of the first things that happens is that the instructions for a source line start to get shuffled with the instructions for another source line. 'step' and 'next' start to look non-sensical, but with some practice you get used to it. (I know of a research idea to do "semantic stepping" which would find the semantic points of the code and step among them instead of by lines. Alas, there's not much funding for debugger research these days...) loop unrolling starts to replicate a variable, and the compiler may have given each instance a different name (such as i_1, i_2, i_3, i_4) and may or may not have told the debug tables about it (if indeed the debug tables have the ability to represent it). Some variables disappear completely because their lifetime is over, or the compiler noticed it was conceptually a temporary and threw it away as it folded its computation into whereever it was used. The list goes on. But from what I've seen, when the user requests optimization and debugability, compilers will honor the optimization request and will do their best with the debugability request. Your milage will vary.