Providing Debugging Information

Perhaps the most common way to provide project debugging information to the assembler is to let the assembler itself automatically generate the information. This level of debugging information means that the debugger source window can display the assembly source file. It also means that you can step through the assembly code and set breakpoints.

For this automatic generation of debugging information, important points are:

• Avoid directives .debug and .line; using either directive turns off automatic generation.
• For some implementations, the linker requires instructions to be in the .text section, in order for automatic generation to happen.
• In automatic-debug mode, the assembler puts everything into a single function (the assembler does not know how source code may be divided into functions). Accordingly, you may see names such as @DummyFn1 in the debugger stack window. But if you wish, you can use the .function directive to divide the code into sections.
• When you debug the assembly-language code, the code may seem spaghetti-like and it may not create valid call frames on the stack. This is normal for the assembler. Because of this, however, the debugger cannot provide stack-crawl information.

An alternative method is providing debugging information to the assembler explicitly, via the debugging directives .file, .function, .line, .size, and .type. This would be particularly appropriate if you were developing a new compiler that output assembly source code: these directives would relate the assembler code back to the original source-code input to the new compiler. But you must avoid the .debug directive, which tells the assembler to ignore the debugging directives.

A final method of providing debugging information, rare in normal use, is using the .debug directive to create an explicit debug section. Such a section might begin:

  .debug
  .long  1 
  .asciz  "MyDebugInfo"

But remember that the .debug directive deactivates any of the debugging directives.