Linux
PC
application gdb debugging:
1. View Core file parameters
[email protected]:~/file_unzip/cp_module$ ulimit-a
Core File Size(blocks,-c) 0//number of core files generated, no core file generated
Data seg Size (Kbytes,-D) Unlimited
scheduling Priority (-e) 0
file Size (blocks,-f) Unlimited
pending Signals (-i) 31042
Max locked Memory (Kbytes,-L)
max memory Size (Kbytes,-m) unlimited
open Files (-N) 1024x768
pipe Size (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 the
core file size to produce
Ulimit-c Unlimited (does not limit the size of the core file)
(The default does not present PID information,You can modify this file by using the following command: echo "1" >/proc/sys/kernel/core_uses_pid, so each time the program is hung it will generate a similar core.8909 (8909 is the process number at that time), The effect is that the core file generated by the subsequent build does not overwrite the previously generated core file. )
3. After generating a segment error, review the process information
Gcc-g test.c-o Test (set GDB Debug)
Ls-l core.*
4. Before using GDB to debug the core file View Core file information: File core
5. Debug the core file with GdB GDB--core=core. Pid
(GDB) bt (stack information does not appear for the first time)
(gdb) file./a.out (Run program)
(GDB) bt (backtrace information appears)
(can be directly used command: ULIMIT-A; Ulimit-c Unlimited;ulimit-a;echo "1" >/proc/sys/kernel/core_uses_pid)
LINUX 
arm
application arm-xxxx-gdb Debug:
1. View Core file parameters
[Email protected]:~/file_unzip/cp_module$ ulimit-a
Core File Size(blocks,-c) 0//number of core files generated, no core file generated
Data seg Size (Kbytes,-D) Unlimited
scheduling Priority (-e) 0
file Size (blocks,-f) Unlimited
pending Signals (-i) 31042
Max locked Memory (Kbytes,-L)
max memory Size (Kbytes,-m) unlimited
open Files (-N) 1024x768
pipe Size (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 the
core file size to produce
Ulimit-c Unlimited (does not limit the size of the core file)
(The default does not present PID information,You can modify this file by using the following command: echo "1" >/proc/sys/kernel/core_uses_pid, so each time the program is hung it will generate a similar core.8909 (8909 is the process number at that time), The effect is that the core file generated by the subsequent build does not overwrite the previously generated core file. )
3. Compile Program Options
Join gdb debug Option arm-linux-xxx-g test.c-o test
4. Build Gdb+gdb Server NFS Debug Method
(1) Ensure that the arm Development Board and Host support NFS functionality, set up the board and host on the same network segment, and set up a shared directory (such as/MNT/NFS). (2) Copy the compiler to the shared directory (/MNT/NFS) for the expected Gdbserver and test (executable file), modify the application and Gdbserver permissions to 777.
(3) Login to the Development Board via Telnet or minicom, Hang on 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 run Gdbserver to establish a remote debugging server (in the format:./gdbserver host IP: Establish the port number of the connection executable file "where the port number is generally above 1024 is not occupied", as 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 (Run command after GDB Debug, connect gdbserver)
Note: The set Solib-absolute-prefix and set Solib-search-path commands are used to set the GDB shared library lookup path prefix and the shared library lookup path, to prevent GDB from locating the library on the host. If you do not specify these paths, GDB loads the host's library during remote debugging and will appear such as "Warning:gdb can t find the start of the function at 0x******" with "Cannot find bounds of CU rrent function "error prompt. The article mainly comes from reference, summary and practice.
GdB debugging Linux PC and Linux arm environments
