Although programming languages generally have common aspects, they are rarely expressed in the same manner. For instance, in ANSI C, dereferencing a pointer p is accomplished by *p, but in Modula-2, it is accomplished by p^. Values can also be represented (and displayed) differently. Hex numbers in C appear as 0x1ae, while in Modula-2 they appear as 1AEH.
Language-specific information is built into gdb for some languages, allowing you to express operations like the above in your program's native language, and allowing gdb to output values in a manner consistent with the syntax of your program's native language. The language you use to build expressions is called the working language.
There are two ways to control the working language--either have gdb set it automatically, or select it manually yourself. You can use the set language command for either purpose. On startup, gdb defaults to setting the language automatically. The working language is used to determine how expressions you type are interpreted, how values are printed, etc.
In addition to the working language, every source file that gdb knows about has its own working language. For some object file formats, the compiler might indicate which language a particular source file is in. However, most of the time gdb infers the language from the name of the file. The language of a source file controls whether C++ names are demangled--this way backtrace can show each frame appropriately for its own language. There is no way to set the language of a source file from within gdb, but you can set the language associated with a filename extension. Refer to Section 14.2 Displaying the language.
This is most commonly a problem when you use a program, such as cfront or f2c, that generates C but is written in another language. In that case, make the program use #line directives in its C output; that way gdb will know the correct language of the source code of the original program, and will display that source code, not the generated C code.
If a source file name ends in one of the following extensions, then gdb infers that its language is the one indicated.
C source file
C++ source file
Objective-C source file
Fortran source file
Modula-2 source file
Assembler source file. This actually behaves almost like C, but gdb does not skip over function prologues when stepping.
In addition, you may set the language associated with a filename extension. Refer to Section 14.2 Displaying the language.
If you allow gdb to set the language automatically, expressions are interpreted the same way in your debugging session and your program.
If you wish, you may set the language manually. To do this, issue the command set language lang, where lang is the name of a language, such as c or modula-2. For a list of the supported languages, type set language.
Setting the language manually prevents gdb from updating the working language automatically. This can lead to confusion if you try to debug a program when the working language is not the same as the source language, when an expression is acceptable to both languages--but means different things. For instance, if the current source file were written in C, and gdb was parsing Modula-2, a command such as:
print a = b + c |
might not have the effect you intended. In C, this means to add b and c and place the result in a. The result printed would be the value of a. In Modula-2, this means to compare a to the result of b+c, yielding a BOOLEAN value.
To have gdb set the working language automatically, use set language local or set language auto. gdb then infers the working language. That is, when your program stops in a frame (usually by encountering a breakpoint), gdb sets the working language to the language recorded for the function in that frame. If the language for a frame is unknown (that is, if the function or block corresponding to the frame was defined in a source file that does not have a recognized extension), the current working language is not changed, and gdb issues a warning.
This may not seem necessary for most programs, which are written entirely in one source language. However, program modules and libraries written in one source language can be used by a main program written in a different source language. Using set language auto in this case frees you from having to set the working language manually.