- That gdb should provide basic literals and access to operations for arithmetic, dereferencing, field selection, indexing, and subprogram calls, leaving more sophisticated computations to subprograms written into the program (which therefore may be called from gdb).
- That type safety and strict adherence to Ada language restrictions are not particularly important to the gdb user.
- That brevity is important to the gdb user.
Thus, for brevity, the debugger acts as if all names declared in user-written packages are directly visible, even if they are not visible according to Ada rules, thus making it unnecessary to fully qualify most names with their packages, regardless of context. Where this causes ambiguity, gdb asks the user's intent.
The debugger will start in Ada mode if it detects an Ada main program. As for other languages, it will enter Ada mode when stopped in a program that was translated from an Ada source file.
While in Ada mode, you may use `–' for comments. This is useful mostly for documenting command files. The standard gdb comment (#) still works at the beginning of a line in Ada mode, but not in the middle (to allow based literals).
The debugger supports limited overloading. Given a subprogram call in which
the function symbol has multiple definitions, it will use the number of
actual parameters and some information about their types to attempt to narrow
the set of definitions. It also makes very limited use of context, preferring
procedures to functions in the context of the
call command, and
functions to procedures elsewhere.