Revision as of 04:39, 18 September 2021

gdb GNU Debugger

2021-09-17 Debugging Zephyr applications:

• https://docs.zephyrproject.org/latest/guides/west/build-flash-debug.html#west-build-flash-debug

Openocd reference:

• https://openocd.org/doc/html/GDB-and-OpenOCD.html
• https://openocd.org/doc/pdf/openocd.pdf 2020-09-13 dated version of `openocd` manual
• https://openocd.org/doc/html/GDB-and-OpenOCD.html URL repeated here, see line:
  

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.

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

• https://stackoverflow.com/questions/11004374/watch-a-memory-range-in-gdb

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