Detailed explanation of the basic usage of the Linux debugger GDB

1. Overview

Three ways of GDB debugging:

1. The target board is debugged directly using GDB.

2. The target board uses gdbserver and the host uses xxx-linux-gdb as the client.

3. The target board uses ulimit -c unlimited to generate a core file; then the host uses xxx-linux-gdb ./test ./core.

2. gdb debugging

Construct the test program as follows main.c and sum.c as follows:

main.c: #include <stdio.h>
#include <stdlib.h>
 
extern int sum(int value);
 
struct inout {
    int value;
    int result;
};

int main(int argc, char * argv[])
{
    struct inout * io = (struct inout * ) malloc(sizeof(struct inout));
    if (NULL == io) {
        printf("Malloc failed.\n");
        return -1;
    }

    if (argc != 2) {
        printf("Wrong para!\n");
        return -1;
    }

    io->value = *argv[1] - '0';
    io->result = sum(io->value);
    printf("Your enter: %d, result:%d\n", io->value, io->result);
    return 0;
}
sum.c:
int sum(int value) {
    int result = 0;
    int i = 0;
    for (i = 0; i < value; i++)
        result += (i + 1);
    return result;
}

Then gcc main.c sum.c -o main -g, get the main executable file.

The following introduces most of the functions of gdb. 1.1 Setting breakpoints and 1.3 Displaying stack frames are commonly used functions. During debugging, 1.6 Single-step execution, 1.4 Displaying variables, 1.5 Displaying registers, 1.8 Watchpoints, and 1.9 Changing variable values ​​may be required.

If the process is already running, you need to attach to the process in 1.11 or generate a dump file for analysis in 1.10. Of course, in order to improve efficiency, you can customize the 1.13 initialization file.

2.1. Set breakpoints

You can set breakpoints by using b or break. Breakpoints can be set by function name, line number, file name + function name, file name + line number, offset, address, etc.

The format is:

break function name

break line number

break file name: function name

break filename:line number

break + offset

break - offset

break *address

Check the breakpoints and view the breakpoint list through info break.

Deleting breakpoints via commands include:

delete <breakpoint id>: delete the specified breakpoint

delete: delete all breakpoints

clear

clear function name

clear line number

clear filename:line number

clear file name: function name

Breakpoints can also be conditionally broken

break breakpoint if condition; for example, break sum if value==9, the execution will stop only when the input value is 9.

condition breakpoint number: delete the trigger condition for the specified breakpoint

condition Breakpoint number condition: add a trigger condition to the specified breakpoint

As can be seen below, when the input parameter is 9, it is interrupted, and when the input parameter is 8, it runs to the end.

Breakpoints can also be temporarily disabled or enabled using disable/enable.

disable

disable breakpoint number

disable display Display number

disable mem memory area

enable

enable breakpoint number

enable once breakpoint number: This breakpoint is enabled only once. After the program runs to this breakpoint and pauses, the breakpoint is disabled.

enable delete breakpoint number

enable display display number

enable mem memory area

2.1.1. Breakpoint commands advanced features

Most of the time, you need to execute a series of actions at a breakpoint. gdb provides an advanced function called commands to execute commands at breakpoints.

#include <stdio.h>

int total = 0;

int square(int i)
{
    int result=0;

    result = i*i;

    return result;
}

int main(int argc, char **argv)
{
    int i;

    for(i=0; i<10; i++)
    {
        total += square(i);
    }
    return 0;
}

For example, we need to breakpoint when the square parameter i is 5 in the above program, and print the values ​​of the stack, local variables and total at this time.

Write gdb.init as follows:

set logging on gdb.log


b square if i == 5
commands
  bt full
  i locals
  p total
  print "Hit break when i == 5"
end

In the gdb shell, source gdb.init and then execute the command r. The results are as follows:

It can be seen that the breakpoint is broken when i==5, and the correct value is printed at this time.

2.2. Operation

After "gdb command", run can run the command under gdb; if the command requires parameters, they follow run.

If you need a breakpoint at main(), just execute start directly.

2.3. Display stack frame

If a breakpoint is encountered, execution is paused, or coredump can display the stack frame.

bt can display the stack frame, and bt full can display local variables.

The command format is as follows:

bt

bt full: not only displays backtrace, but also local variables

bt N: Display the first N stack frames

bt full N

2.4. Display variables

"print variable" can display the content of the variable.

If you need to monitor multiple variables in one line, you can use p {var1, var2, var3}.

If you want to track automatic display, you can use display {var1, var2, var3}

2.5. Display register

info reg can display the register contents.

Add $ before the register name to display the register content.

p $register: display register contents

p/x $register: Display register contents in hexadecimal.

Use the x command to display the content, "x/format address".

x $pc: Display the program pointer content

x/i $pc: Display program pointer assembly.

x/10i $pc: Display 10 instructions after the program pointer.

x/128wx 0xfc207000: Print 128 words in hexadecimal starting from 0xfc20700.

You can also disassemble it using the disassemble command.

disassemble

disassemble Program Counter: disassemble the entire function where pc is located.

disassemble addr-0x40,addr+0x40: disassemble addr with 0x40 before and after.

2.6. Single step execution

There are two commands for single-step execution: next and step. The difference between the two is that next will not enter the function when encountering a function, but step will execute into the function.

If you need to execute assembly instructions one by one, you can use nexti and stepi respectively.

2.7. Continue execution

When debugging, use the continue command to continue program execution. The program will pause again after a power outage; if there is no breakpoint, it will continue to execute to the end.

continue: continue execution

continue times: continue execution a certain number of times.

2.8. Monitoring Points

To find out where a variable is changed, you can use the watch command to set a watchpoint.

watch <expression>: Pause when the expression changes

awatch<expression>: expression is accessed, changes are paused

rwatch<expression>: Pause execution when expression is accessed

Other variants include watch expr [thread thread-id] [mask maskvalue], where mask requires architecture support.

GDB cannot monitor a constant, for example, watch 0x600850 will report an error.

But you can watch *(int *)0x600850.

2.9. Change the value of a variable

Modify the value of a variable by “set variable <variable>=<expression>”.

set $r0=xxx: Set the value of register r0 to xxx.

2.10. Generate a kernel dump file

Generate a core.xxxx dump file via "generate-core-file".

Then use gdb ./main ./core.xxxx to view the restored scene.

Another command, gcore, can generate a core dump file directly from the command line.

gcore `pidof command`: Get dump file without stopping the executing program.

2.11. Attach to the process

If the program is already running, or the debugging is stuck in an infinite loop and cannot return to the console process, you can use the attach command.

attach pid

You can view the pid of the process through ps aux, and then use bt to view the stack frame.

Taking top as an example, the operation steps are as follows:

1. ps -aux to view the process pid, which is 16974.

2. sudo gdb attach 16974, use gdb to attach to the top command.

3. Use bt full to view the current stack frame. At this time, use print etc. to view the information.

4. You can also view process information through info proc.

2.12. Repeated execution

continue, step, stepi, next, and nexti can all specify the number of repeated executions.

ignore breakpoint number times: you can ignore the specified number of breakpoints.

2.13. Initialization File

The initialization file in Linux environment is .gdbinit.

If a .gdbinit file exists, gdb runs it as a command file before starting up.

The execution order of initialization files and command files is: HOME/.gdbinit > run command line options > ./.gdbinit > -x specifies the command file.

2.14. Set the source directory

If you need to associate with the source code during debugging, view more detailed information.

The source directory can be specified via directory or set substitute-path.

2.15 TUI debugging

TUI (TextUserInterface) is the text user interface for GDB debugging, which can conveniently display source code, assembly and register text windows.

The source code window and assembly window will highlight the program execution location and mark it with a '>' symbol. There are two special tags used to identify breakpoints. The first tag identifies the breakpoint type:

• B： The program has reached this breakpoint at least once.
• b： The program has not run to this breakpoint
• H： The program has reached this hardware breakpoint at least once.
• h： The program has not run to this hardware breakpoint

The second flag is used to indicate whether the breakpoint is enabled or not:

+： Breakpoint is enabled. -： Breakpoint is disabled.

When debugging a program, the contents of the Source Code Window, Assembly Window, and Register Window are automatically updated.

2.16 Catchpoint

Catch can stop program execution based on certain types of events.

You can use catch syscall close to stop program execution when the system call close is generated.

Other catch events include throw, syscall, assert, exception, etc.

2.17 Custom Scripts

The input parameters of the command line can be obtained through argc and *argv.

2.17.0, Annotation, Assignment, Display

# - Add comments to the script.

set - assigns a value to a variable, starting with $ to distinguish between gdb and debugger variables.

For example: set $x = 1

Display variables can be done through echo and printf.

2.17.1 Custom Commands

You can use the define command to define your own commands, and you can also use the document command to add descriptions to your custom commands.

define adder
  if $argc == 2
    print $arg0 + $arg1
  end
  if $argc == 3
    print $arg0 + $arg1 + $arg2
  end
end

document adder
  Sum two or three variables.
end

Execute the bf custom command, and the results are as follows.

There is no row parameter declaration, but it can be directly referenced using $arg0, $arg1, $argc is the number of formal parameters

2.17.2 Conditional Statements

Conditional commands: if...else...end . This is no different from the if command provided in other languages, just pay attention to the end .

2.17.3 Loop Statement

Loop command: while...end . gdb also provides loop_break and loop_continue commands corresponding to break and continue in other languages ​​respectively. Also pay attention to the end .

set logging on overwrite gdb.log------------Save the displayed log to gdb.log.
set pagination off--------------------------Turn off the paging display function.

tar jtag jtag://localhost:1025--------------Connect to JTAG.

d----------------------------------------------Delete an existing breakpoint.

b func_a------------------------------------Add a breakpoint in func_a.
commands------------------------------------After the breakpoint, execute the following commands.
  b func_b----------------------------------After the breakpoint in func_a, add a breakpoint in func_b.
    commands bt full-------------------------------Print the stack frame at func_b.
      c-------------------------------------Continue execution.
    end
  b file.c:555------------------------------Add a breakpoint command at line 555 of file.c
      while 1-------------------------------Execute the next command infinitely.
        next
      end
    end
  c-----------------------------------------Continue execution to trigger the func_b and file.c:555 breakpoints.
end

c------------------------------------------- means the program continues to execute.

You can also update the script in the command line gdb -x gdb.init bin; or gdb bin and then source gdb.init in the command line.

2.18. Dump memory to a specified file

During gdb debugging, you may need to export a section of memory to a file, which can be done with the help of the dump command.

Command format:

dump binary memory FILE START STOP

For example, dump binary memory ./dump.bin 0x0 0x008000000 will export the memory range from 0x0 to 0x00800000 to dump.bin.

3. gdb+gdbserver remote debugging

The target board gdbserver + host gdb remote debugging method is more suitable for target boards with limited performance and can only provide gdbserver functions.

Run gdb on the host computer for remote debugging. The test procedure is as follows.

#include <stdio.h>

void C(int *p)
{
    *p = 0x12;
}

void B(int *p)
{
    C(p);
}
void A(int *p)
{
    B(p);
}
void A2(int *p)
{
    C(p);
}
int main(int argc, char **argv)
{
    int a;
    int *p = NULL;
    A2(&a); // A2 > C
    printf("a = 0x%x\n", a);
    A(p); // A > B > C
    return 0;
}

The target board is set up as follows: open port 2345 as the gdbserver copper port.

gdbserver :2345 test_debug

Execute gdb test_debug on the host, and then tar remote 192.168.2.84.2345 to connect to the remote gdbserver.

The target board will receive the message "Remote debugging from host 192.168.33.77", indicating that the connection between the two is successful.

Remote debugging can be performed on the host. After continue, the results obtained at both ends are as follows:

The target board stops running after outputting "a=0x12".

The host receives SIGSEGV and can view backtrace information. It can be seen that the problem lies in the pointer p pointing to NULL, and the 0 pointer assignment is wrong.

4. Offline analysis through core+gdb

Run ulimit -c unlimited on the target board and execute the application.

When a program error occurs, a core file will be generated in the current directory.

After copying the core file, execute xxx-linux-gdb ./test ./core on the PC for analysis.

4.1、Load library files

After running xxx-linux-gdb ./test ./core, the library files may not be associated.

Use info sharedlibrary to view the library loading status.

From To Syms Read Shared Object Library
                        No xxx.so
                        No /lib/libdl.so.2
                        No /lib/libpthread.so.0
0x2ab6ec00 0x2ac09ba4 Yes xxx/lib/libstdc++.so.6
                        No /lib/libm.so.6
0x2acec460 0x2acf626c Yes xxx/lib/libgcc_s.so.1
                        No /lib/libc.so.6
                        No /lib/ld.so.1

It can be set by set solib-search-path and set solib-absolute-prefix, corresponding to the path where the library is located.

From To Syms Read Shared Object Library
0x2aaca050 0x2aacc8d0 Yes xxx.so
0x2aad0ad0 0x2aad17ac Yes (*) xxx/lib/libdl.so.2
0x2aad8a50 0x2aae7434 Yes (*) xxx/lib/libpthread.so.0
0x2ab6ec00 0x2ac09ba4 Yes xxx/lib/libstdc++.so.6
0x2ac4b3d0 0x2acb1988 Yes xxx/lib/libm.so.6
0x2acec460 0x2acf626c Yes xxx/lib/libgcc_s.so.1
0x2ad17b80 0x2adf699e Yes xxx/lib/libc.so.6
0x2aaa89e0 0x2aabf66c Yes (*) xxx/lib/ld.so.1
(*): Shared library is missing debugging information.

It can be seen that the relevant library files have been loaded, but some library files have no debugging information.

4.2. View backtrace

To view the backtrace of coredump, use bit t. For more complete information, use bit t full.

Several functions that produce function call stack

bt: Displays information about all function call stack frames, one line per frame.

bt n: Display information of n frames in the stack.

bt -n: Displays n frames of information at the bottom of the stack.

bt full: Displays complete information of all frames in the stack, such as function parameters and local variables.

bt full n: Same usage as above.

bt full -n

(gdb) bt
#0 0x2ad71f1e in memcpy () from xxx/lib/libc.so.6
#1 0x2ad71ac0 in memmove () from xxx/lib/libc.so.6
#2 0x0011f36c in std::__copy_move<false, true, std::random_access_iterator_tag>::__copy_m<unsigned char> (__first=0x34dfb008 "\377\330\377", <incomplete sequence \340>, __last=0x34eeea2c "", 
    ...
#3 0x0011ee22 in std::__copy_move_a<false, unsigned char*, unsigned char*> (__first=0x34dfb008 "\377\330\377", <incomplete sequence \340>, __last=0x34eeea2c "", __result=0x2b2013c0 "\377\330\377", <incomplete sequence \340>)
    at xxxinclude/c++/6.3.0/bits/stl_algobase.h:386
#4 0x0011e7e2 in std::__copy_move_a2<false, __gnu_cxx::__normal_iterator<unsigned char*, std::vector<unsigned char> >, unsigned char*> (__first=..., __last=..., __result=0x2b2013c0 "\377\330\377", <incomplete sequence \340>)
    at xxx/bits/stl_algobase.h:424
#5 0x0011dfd2 in std::copy<__gnu_cxx::__normal_iterator<unsigned char*, std::vector<unsigned char> >, unsigned char*> (__first=..., __last=..., __result=0x2b2013c0 "\377\330\377", <incomplete sequence \340>)
    at xxx/6.3.0/bits/stl_algobase.h:456
#6 0x0011c948 in xxx
#7 0x00133e08 in xxx
#8 0x2aada31e in start_thread () from xxx/libc/lib/libpthread.so.0
#9 0x005a11b4 in ?? ()

4.3 Core Dump storage file directory and naming rules

By default, the core file is stored in the current application path, and can be set for distinction.

The cores are mainly distinguished through /proc/sys/kernel/core_uses_pid and /proc/sys/kernel/core_pattern.

/proc/sys/kernel/core_uses_pid: It can control whether pid is added as an extension in the file name of the generated core file. If it is added, the file content is 1, otherwise it is 0.

proc/sys/kernel/core_pattern: You can set the formatted core file save location or file name, for example, the original file content is core-%e

echo "/tmp/core-%e-%p" > core_pattern.

The generated core file will be stored in the /corefile directory. The generated file name is core-command name-pid-timestamp

The following is a list of parameters:

%p - insert pid into filename
%u - insert current uid into filename
%g - insert current gid into filename
%s - insert signal that caused the coredump into the filename
%t - insert UNIX time that the coredump occurred into filename Add the UNIX time when the core file was generated
%h - insert hostname where the coredump happened into filename
%e - insert coredumping executable name into filename Add command name

Of course, you can do this in the following ways:

sysctl -w kernel.core_pattern=/tmp/core-%e-%p

4.4 Use of ulimit

Function description: Control the resources of the shell program.

Syntax: ulimit [-aHS][-c <core file upper limit>][-d <data section size>][-f <file size>][-m <memory size>][-n <number of files>][-p <buffer size>][-s <stack size>][-t <CPU time>][-u <number of programs>][-v <virtual memory size>]

Additional note: ulimit is a built-in shell command that can be used to control the resources of the shell execution program.

parameter:

-a Displays the current resource limit settings.
-c <core file upper limit> Set the maximum value of the core file in blocks.
-d <data section size> The maximum value of the program data section, in KB.
-f <file size> The largest file that the shell can create, in blocks.
-H sets a hard limit on the resource, that is, the limit set by the administrator.
-m <memory size> specifies the upper limit of available memory in KB.
-n <number of files> specifies the maximum number of files that can be opened at the same time.
-p <buffer size> specifies the size of the pipe buffer in units of 512 bytes.
-s <stack size> Specifies the upper limit of the stack in KB.
-S Set elastic limits for resources.
-t <CPU time> specifies the upper limit of CPU usage time in seconds.
-u <number of programs> The maximum number of programs a user can open.
-v <virtual memory size> specifies the upper limit of available virtual memory in KB.

5. GDB Tips

5.1. Close

Type <return> to continue, or q <return> to quit---

When the display content is large, GDB will force paging and the display will be suspended. But it may not be needed and can be turned off by setting pagination off.

5.2. Attach to the running kernel

If a crash or other problem occurs on a running Linux, you need to use the jtag connection to locate the problem.

The connection method is:

gdb-----------------------------------------------Enter the gdb shell.

target remote localhost:1025-------------------Connect to target via ip:port in gdb shell.

file vmlinux----------------------------------------Load the symbol table.

Then you can view the running status online.

The above is the detailed content of the basic usage of the Linux debugger GDB. For more information about the Linux debugger GDB, please pay attention to other related articles on 123WORDPRESS.COM!