Gdb debugging: gdbarm in linux pc and linux arm
LinuxPCApplication gdb debugging:
1. View core File Parameters
Yinkui @ yinkui-desktop :~ /File_unzip/cp_module $Ulimit-
Core file size(Blocks,-c) 0 // generate the number of core files without generating core files
Data seg size (kbytes,-d) unlimited
Scheduling priority (-e) 0
File size (blocks,-f) unlimited
Pending signals (-I) 31042
Max locked memory (kbytes,-l) 64
Max memory size (kbytes,-m) unlimited
Open File (-n) 1024
Pipe size (512 bytes,-p) 8
POSIX message queues (bytes,-q) 819200
Real-time priority (-r) 0
Stack size (kbytes,-s) 8192 // application stack size
Cpu time (seconds,-t) unlimited
Max user processes (-u) 31042
Virtual memory (kbytes,-v) unlimited
File locks (-x) unlimited
2. Set to generate
Core File Size
Ulimit-c unlimited (do not limit the size of the core file)
(PID information is not realistic by default. You can run the following command to modify this file: echo "1">/proc/sys/kernel/core_uses_pid, in this way, after each program crashes, a process similar to core.8909 (8909 is the current process number) will be generated. The result is that the subsequently generated core file will not overwrite the previously generated core file .)
3. view the process information after a segment error is generated.
Gcc-g test. c-o test (set gdb debugging)
Ls-l core .*
4. Before using gdb to debug the core FileView core file Information: file core
5. Use gdb to debug the core FileGdb -- core = core. PID
(Gdb) bt (stack information will not appear for the first time)
(Gdb) file./a. out (run the program)
(Gdb) bt (backtrace information appears)
(You can directly use the command: ulimit-a; ulimit-c unlimited; ulimit-a; echo "1">/proc/sys/kernel/core_uses_pid)
Linux
Arm
Application arm-XXXX-gdb debugging:
1. View core File Parameters
Yinkui @ yinkui-desktop :~ /File_unzip/cp_module $Ulimit-
Core file size(Blocks,-c) 0 // generate the number of core files without generating core files
Data seg size (kbytes,-d) unlimited
Scheduling priority (-e) 0
File size (blocks,-f) unlimited
Pending signals (-I) 31042
Max locked memory (kbytes,-l) 64
Max memory size (kbytes,-m) unlimited
Open File (-n) 1024
Pipe size (512 bytes,-p) 8
POSIX message queues (bytes,-q) 819200
Real-time priority (-r) 0
Stack size (kbytes,-s) 8192
Cpu time (seconds,-t) unlimited
Max user processes (-u) 31042
Virtual memory (kbytes,-v) unlimited
File locks (-x) unlimited
2. Set to generate
Core File Size
Ulimit-c unlimited (do not limit the size of the core file)
(PID information is not realistic by default. You can run the following command to modify this file: echo "1">/proc/sys/kernel/core_uses_pid, in this way, after each program crashes, a process similar to core.8909 (8909 is the current process number) will be generated. The result is that the subsequently generated core file will not overwrite the previously generated core file .)
3. compile program options
Add the gdb debugging Option arm-linux-XXX-g test. c-o test
4. Build the GDB + GDB server nfs debugging method
(1) Ensure that the arm Development Board and Host Support the nfs function, set the Development Board and host to the same network segment, and set the shared directory (such as/mnt/nfs ). (2) copy the gdbserver and test (executable files) to the shared directory (/mnt/nfs) by the compiler, and set the application and gdbserver permissions to 777.
(3) log on to the Development Board through telnet or minicom and mount the nfs file system: mount-t nfs Host IP:/mnt/nfs (shared directory) /home/root/modbus_rtu_slave (Development Board directory)-o nolock
(4) enter the shared directory and run gdbserver to establish a remote debugging server (Format :. /gdbserver Host IP Address: the executable file of the port number for establishing a connection [where the port number is generally above 1024 and is not occupied], as shown below ). /gdbserver 10.10.51.47: 5000 test
(5) run the executable program in the host directory:
Arm-linux-gdb test
--- "Target remote 10.10.51.33: 5000 (enter gdb for debugging and run the command to connect to gdbserver)
Note: The set solib-absolute-prefix and set solib-search-path commands are used to set the path prefix of the GDB shared library and the path of the shared library to prevent GDB from searching for the libraries on the host. If you do not specify these paths, GDB loads the host machine library during the remote debugging process, such as "warning: GDB can't find the start of the function at 0x ****** "and" Cannot find bounds of current function. This article mainly comes from references, summaries, and practices.
