"Software debugging Art" book Three

1, GDB Debugging technology

Before talking about this problem before we have encountered this scenario, each time to change the code, then make, after GdB debugging, and then out of GDB quit, again change make again made GDB again quit repeatedly a work. Is there any way to avoid this recurring thing? After all, the program ape is very disgusted with this repeated step.

The way to avoid this is for example: when we open a separate form for code churn and compilation, this form is designed to be used to modify and compile. GdB Debug form does not close. When the Run (r) command is entered below the GDB command line. GDB can load the newly compiled program again.

At this point, the breakpoint set is still there, where the breakpoint does not contain a temporary breakpoint, which you know. It's just a deviation, why is there a bias, because the line number of the breakpoint that was set previously or the line number that was used, but now the code is likely to join a lot. This creates a certain deviation.

In the actual project. A project can not be completed one day, and sometimes the computer is to shut down, the shutdown may be active, it may be passive.

This way, the breakpoints that were set before the restart are gone, and we are able to write all of our inductive debugs into the. gdbinit file, where the location of the file has been described earlier, and you can not remember to read the previous article.

2. Clear breakpoints or monitor viewpoints

Deleting a breakpoint or a supervisor can use the Delete command, such as the following command format:

Deletebreakpoint-list

Delete Does not add a number to remove all breakpoints. But it needs to be confirmed so that you don't have to be mistaken, assuming you don't need confirmation. You need to write the set Confirmoff shutdown acknowledgement function in the. gdbinit enable file.

Clear command: Clear the breakpoint at the next command that GDB will run, using a method that is in addition to the breakpoint to which GDB has reached.

Use the following methods for example:

Clear function, Filename:function, Line-number, and Filename:line-number. Each breakpoint can be enabled or disabled.

Just when GdB encounters an enabled breakpoint, it pauses the program's run, ignoring the forbidden breakpoint.

3. Disable and enable breakpoints

Disable the breakpoint-list command to disable breakpoints. Use the Enable Breakpoint-list command to turn on breakpoints, breakpoint-list use a list of space separators.

Running the Disable command without any of the parameters will prohibit all breakpoints. The enable command without any parameters enables all breakpoints. The Enable once command is enabled once and will be disabled once it is run once.

So the deployment of a breakpoint is divided into three states: Keep (Hold), Del (delete), and dis (disabled).

4, Next and step commands

Next is called stepping over, step is stepping into. The next (n) command runs the function and does not pause in it, i.e. it does not enter the inside of the function body. Both this command and the step (s) command are single-step debugging. But the s command goes inside the function.

Such as:

A = 5;

b = 10;

result = Add (a, b);

printf ("%d\n", result);

Assuming next is debugging, next does not enter the Add function. It pauses at the printf statement, assuming that the step command is used, and pauses the first statement in the Add function.

Nextcount is equivalent to running the Count next command separately, while continue count means ignoring the next count breakpoint.

5. Finish command

Fin command: Instructs GDB to resume running, knowing that exactly after the current buyers frame has finished, the proper function is returned.

6. Until command

Until the recovery program runs, the Until command (U) pass is often used to complete a running loop without further pauses in the loop. Use methods such as the following:

Until count, until function, until Filename:line-number, until Filename:function

"Software debugging Art" book Three