Gdb

From Wiki at Neela Nurseries
Revision as of 15:12, 18 September 2021 by Ted (talk | contribs) (→‎^ openocd Adapter Definitions Files)
Jump to: navigation, search

gdb GNU Debugger


^ To Use openocd With Zephyr Projects

2021-09-17 Debugging Zephyr applications:

Openocd reference:

    However for some, eg. FreeRTOS, uC/OS-III and Zephyr, extra steps must be taken. Zephyr must be compiled with the DEBUG_THREAD_INFO option. This will generate some symbols with information needed in order to build the list of threads.


Zephyr project and DEBUG_THREAD_INFO symbol use, location in Kconfig files:


^ First Page Entry or Section

How to have gdb stop on access to a memory location within a range of memory addresses, popular solution mentions use of valgrind:

An excerpt from above StackOverflow page to highlight the issue: 

11

I am debugging a program in gdb and I want the program to stop when the memory region 0x08049000 to 0x0804a000 is accessed. When I try to set memory breakpoints manually, gdb does not seem to support more than two locations at a time.

(gdb) awatch *0x08049000
Hardware access (read/write) watchpoint 1: *0x08049000
(gdb) awatch *0x08049001
Hardware access (read/write) watchpoint 2: *0x08049001
(gdb) awatch *0x08049002
Hardware access (read/write) watchpoint 3: *0x08049002
(gdb) run
Starting program: /home/iblue/git/some-code/some-executable
Warning:
Could not insert hardware watchpoint 3.
Could not insert hardware breakpoints:
You may have requested too many hardware breakpoints/watchpoints.

There is already a question where this has been asked and the answer was, that it may be possible to do this with valgrind. Unfortunately the answer does not contain any examples or reference to the valgrind manual, so it was not very enlightning: How can gdb be used to watch for any changes in an entire region of memory?

So: How can I watch the whole memory region?
c
linux
debugging
gdb
Share
Improve this question
Follow
edited May 23 '17 at 12:32
Community♦
111 silver badge
asked Jun 12 '12 at 20:30
iblue
26.9k1818 gold badges8282 silver badges125125 bronze badges

    Interesting fact: PowerPC has ranged breakpoints (but not watchpoints ?): stackoverflow.com/questions/13410941/… – Ciro Santilli 新疆再教育营六四事件法轮功郝海东 Jul 27 '15 at 16:09
    x86 supports small watch ranges up to 8 bytes: en.wikipedia.org/wiki/X86_debug_register – Ciro Santilli 新疆再教育营六四事件法轮功郝海东 Aug 12 '15 at 12:09

Add a comment
2 Answers
29

If you use GDB 7.4 together with Valgrind 3.7.0, then you have unlimited "emulated" hardware watchpoints.

Start your program under Valgrind, giving the arguments --vgdb=full --vgdb-error=0 then use GDB to connect to it (target remote | vgdb). Then you can e.g. watch or awatch or rwatch a memory range by doing rwatch (char[100]) *0x5180040

See the Valgrind user manual on gdb integration for more details
Share
Improve this answer
Follow
edited Jun 17 '12 at 17:57
iblue
26.9k1818 gold badges8282 silver badges125125 bronze badges
answered Jun 13 '12 at 20:00
phd
52133 silver badges33 bronze badges

    4
    After I spent the better part of the day fiddling with mprotect and abusing SIGSEV handlers to break on memory access, I tried this. It works perfectly. You saved my day. Thank you! – iblue Jun 13 '12 at 23:00
    Yes, +1 also. I've been hunting for a feature like this for months. – Crashworks Jun 14 '12 at 0:10
    So, how does one determine the heap address for the process started by valgrind? I usually do this via /proc/[pid]/maps but when I start python via this valgrind command, the maps file doesn't have an entry identified by [heap] as I'm used to finding. – Andrew Falanga Feb 11 '16 at 19:59 

I realise that this answer was written a long time ago, but I am confused by this answer, because gdb can do that by itself, without valgrind's help. At least it can now. It will resort to single-step and check repeatedly. That's obviously really expensive (like valgrind is), so you would narrow it down to when the corruption is about to happen soon, then create the watchpoint, so you don't have it running slow the whole debug run. – doug65536 Dec 10 '20 at 3:40


^ openocd Adapter Definitions Files

Mentioned in [ openocd documentation entry point] this debugging utility typically requires two key configuration files, one config file to describe the often physical, hardware based programming and debugging adapter, and a config file to describe the targeted board or SoC where firmware that is running will be debugged.

Temporary learning note here, local instances of openocd's "ships with" adapter files: 

/home/ted/projects/openocd-code/tcl/interface/ftdi/
/home/ted/zephyr-sdk-0.12.4/sysroots/x86_64-pokysdk-linux/usr/share/openocd/scripts/interface/ftdi/
/opt/zephyr-sdk-0.12.4/sysroots/x86_64-pokysdk-linux/usr/share/openocd/scripts/interface/ftdi
/usr/local/share/openocd/scripts/interface/ftdi

Ugh, which one of these is referenced when calling `west debug` on a given local Zephyr project? . . . want to answer this - TMH

Invoking `west -v debug` gives: 

ted@localhost:~/projects/zephyr-based/z9/aws-iot-stand-alone$ west -v debug
ZEPHYR_BASE=/home/ted/projects/zephyr-based/z9/zephyr (origin: configfile)
-- west debug: rebuilding
cmake version 3.21.1 is OK; minimum version is 3.13.1
Running CMake: /usr/bin/cmake --build /home/ted/projects/zephyr-based/z9/aws-iot-stand-alone/build
[0/17] Performing build step for 'spm_subimage'
ninja: no work to do.
[1/5] Performing build step for 'mcuboot_subimage'
ninja: no work to do.
-- west debug: using runner jlink
runners.jlink: JLINKARM_GetDLLVersion()=75001
-- runners.jlink: JLink version: 7.50a
-- runners.jlink: J-Link GDB server running on port 2331; thread info enabled
runners.jlink: JLinkGDBServer -select usb -port 2331 -if swd -speed 4000 -device cortex-m33 -silent -singlerun -nogui -rtos /opt/SEGGER/JLink_V750a/GDBServer/RTOSPlugin_Zephyr
runners.jlink: /opt/zephyr-sdk-0.12.4/arm-zephyr-eabi/bin/arm-zephyr-eabi-gdb /home/ted/projects/zephyr-based/z9/aws-iot-stand-alone/build/zephyr/zephyr.elf -ex 'target remote :2331' -ex 'monitor halt' -ex 'monitor reset' -ex load
SEGGER J-Link GDB Server V7.50a Command Line Version

JLinkARM.dll V7.50a (DLL compiled Jul  8 2021 18:20:53)

-----GDB Server start settings-----
GDBInit file:                  none
GDB Server Listening port:     2331
SWO raw output listening port: 2332
Terminal I/O port:             2333
Accept remote connection:      yes
Generate logfile:              off
Verify download:               off
Init regs on start:            off
Silent mode:                   on
Single run mode:               on
Target connection timeout:     0 ms
------J-Link related settings------
J-Link Host interface:         USB
J-Link script:                 none
J-Link settings file:          none
------Target related settings------
Target device:                 cortex-m33
Target interface:              SWD
Target interface speed:        4000kHz
Target endian:                 little

GNU gdb (crosstool-NG 1.24.0.212_d7da3a9) 9.2
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "--host=x86_64-build_pc-linux-gnu --target=arm-zephyr-eabi".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /home/ted/projects/zephyr-based/z9/aws-iot-stand-alone/build/zephyr/zephyr.elf...
Remote debugging using :2331
arch_cpu_idle () at /home/ted/projects/zephyr-based/z9/zephyr/arch/arm/core/aarch32/cpu_idle.S:107
107		cpsie	i
Resetting target
Loading section rom_start, size 0x23c lma 0x20200
Loading section text, size 0x1cd4a lma 0x20440
Loading section .ARM.exidx, size 0x8 lma 0x3d18c
Loading section initlevel, size 0x80 lma 0x3d194
Loading section sw_isr_table, size 0x208 lma 0x3d214
Loading section net_socket_register_area, size 0xc lma 0x3d41c
Loading section log_const_sections, size 0xf0 lma 0x3d428
Loading section zephyr_dbg_info, size 0x3c lma 0x3d518
Loading section device_handles, size 0x38 lma 0x3d554
Loading section rodata, size 0x554c lma 0x3d590
Loading section datas, size 0x3e0 lma 0x42af4
Loading section devices, size 0xa8 lma 0x42ed4
Loading section _static_thread_data_area, size 0x60 lma 0x42f7c
Loading section k_heap_area, size 0x30 lma 0x42fdc
Loading section k_mutex_area, size 0xb4 lma 0x4300c
Loading section k_msgq_area, size 0x68 lma 0x430c0
Loading section k_sem_area, size 0x60 lma 0x43128
Loading section net_if_area, size 0x4 lma 0x43188
Loading section net_if_dev_area, size 0x1c lma 0x4318c
Start address 0x00026050, load size 143238
Transfer rate: 6358 KB/sec, 5305 bytes/write.
(gdb)

Many options given to `openocd` here but not an obvious clue from where `openocd` config files are read and parsed.


 
 

- - - top of page - - -



Retrieved from "https://wiki.neelanurseries.com/index.php?title=Gdb&oldid=4764"