RTEMS GNU Tools On-Line Library

Algorithms

GDB Internals

Chapter 3: Algorithms

GDB uses a number of debugging-specific algorithms. They are often not very complicated, but get lost in the thicket of special cases and real-world issues. This chapter describes the basic algorithms and mentions some of the specific target definitions that they use.

3.1: Frames

A frame is a construct that GDB uses to keep track of calling and called functions.

FRAME_FP in the machine description has no meaning to the machine-independent part of GDB, except that it is used when setting up a new frame from scratch, as follows:

      create_new_frame (read_register (FP_REGNUM), read_pc ()));

Other than that, all the meaning imparted to FP_REGNUM is imparted by the machine-dependent code. So, FP_REGNUM can have any value that is convenient for the code that creates new frames. (create_new_frame calls INIT_EXTRA_FRAME_INFO if it is defined; that is where you should use the FP_REGNUM value, if your frames are nonstandard.)

Given a GDB frame, define FRAME_CHAIN to determine the address of the calling function's frame. This will be used to create a new GDB frame struct, and then INIT_EXTRA_FRAME_INFO and INIT_FRAME_PC will be called for the new frame.

3.2: Breakpoint Handling

In general, a breakpoint is a user-designated location in the program where the user wants to regain control if program execution ever reaches that location.

There are two main ways to implement breakpoints; either as ``hardware'' breakpoints or as ``software'' breakpoints.

Hardware breakpoints are sometimes available as a builtin debugging features with some chips. Typically these work by having dedicated register into which the breakpoint address may be stored. If the PC ever matches a value in a breakpoint registers, the CPU raises an exception and reports it to GDB. Another possibility is when an emulator is in use; many emulators include circuitry that watches the address lines coming out from the processor, and force it to stop if the address matches a breakpoint's address. A third possibility is that the target already has the ability to do breakpoints somehow; for instance, a ROM monitor may do its own software breakpoints. So although these are not literally ``hardware breakpoints'', from GDB's point of view they work the same; GDB need not do nothing more than set the breakpoint and wait for something to happen.

Since they depend on hardware resources, hardware breakpoints may be limited in number; when the user asks for more, GDB will start trying to set software breakpoints.

Software breakpoints require GDB to do somewhat more work. The basic theory is that GDB will replace a program instruction with a trap, illegal divide, or some other instruction that will cause an exception, and then when it's encountered, GDB will take the exception and stop the program. When the user says to continue, GDB will restore the original instruction, single-step, re-insert the trap, and continue on.

Since it literally overwrites the program being tested, the program area must be writeable, so this technique won't work on programs in ROM. It can also distort the behavior of programs that examine themselves, although the situation would be highly unusual.

Also, the software breakpoint instruction should be the smallest size of instruction, so it doesn't overwrite an instruction that might be a jump target, and cause disaster when the program jumps into the middle of the breakpoint instruction. (Strictly speaking, the breakpoint must be no larger than the smallest interval between instructions that may be jump targets; perhaps there is an architecture where only even-numbered instructions may jumped to.) Note that it's possible for an instruction set not to have any instructions usable for a software breakpoint, although in practice only the ARC has failed to define such an instruction.

The basic definition of the software breakpoint is the macro BREAKPOINT.

Basic breakpoint object handling is in `breakpoint.c'. However, much of the interesting breakpoint action is in `infrun.c'.

3.3: Single Stepping

3.4: Signal Handling

3.5: Thread Handling

3.6: Inferior Function Calls

3.7: Longjmp Support

GDB has support for figuring out that the target is doing a longjmp and for stopping at the target of the jump, if we are stepping. This is done with a few specialized internal breakpoints, which are visible in the maint info breakpoint command.

To make this work, you need to define a macro called GET_LONGJMP_TARGET, which will examine the jmp_buf structure and extract the longjmp target address. Since jmp_buf is target specific, you will need to define it in the appropriate `tm-xyz.h' file. Look in `tm-sun4os4.h' and `sparc-tdep.c' for examples of how to do this.

GDB Internals