Seer and Embedded devices.

[epasveer]

I came across an interesting discussion of the gdb debugger and, I assume, specifically using gdb to debug embedded devices.

https://hackaday.com/2022/06/14/linux-fu-up-your-gdb-game/#more-539147

Using Seer (and gdb) to help debug embedded devices is definitely on my radar.

I've created this discussion for people to comment with your ideas, experiences, suggestions, etc. on how you:

• currently debug embedded devices (gdb and other tools)
• how can it be improved

As Seer is actively being worked on by me, I am very keen on improving it. Embedded devices is something I don't have a lot of experience so your input is welcomed and appreciated.

[epasveer]

Of note, I'm interested with:

• how people use gdb now to debug their app (gdb, gdbserver). What gdb settings do they use? What steps?
• are two files involved with embedded devices? An elf file and a .bin file?

[epasveer]

As well, if I were to setup a simple embedded environment (create a 'hello world' app), how would I do so?

[yalfg]

There's another topic that may be related: supporting the fantastic "record and replay" tool.

In replay mode, rr replay acts as a gdb. My (limited) understanding is that rr acts as a remote gdb server interfacing to a gdb front-end. This lets the front-end gdb believes it's interacting with a normal target, while rr controls the replay.

So in effect, rr replay appears to gdb as a remote target. That should be similar to working with an embedded remote device, which also uses a gdb server.

So maybe supporting rr replay with seer would be a good preparation for embedded support? And no need for a device ;) Also, supporting rr is a good thing on its own. After discovering it, I simply can't imaging using a "real" gdb debug session. It's always record and replay for me.

One limitation I've seen in replay mode, that may also happen when using embedded gdb, is the printing of debug output. With some gdb debug front-end (emacs gdb mode for example), the console output in replay mode is regularly halted (type return to continue). The issue is that this return not only unblock text output, but is also passed to the remote gdb. So after a wall of text, the last command is executed as many times as return was pressed. A gdb front-end smoothly supporting replay mode would be nice.

Thanks

[epasveer]

Many thanks! I'll check it out.

[chelm-dev]

I use the ESP32-WROVER with the ESP-PROG debugger with GDB & openocd.
It's a very inexpensive way to get into embedded dev.

The openocd & gdb are installed as part of the esp-idf build system.

./openocd-esp32/bin/openocd.exe -f board/esp32-wrover-kit-3.3v.cfg

$ cat gdbinit
target remote :3333
set remote hardware-watchpoint-limit 2
#mon reset halt
flushregs
set print elements 0
set print array on

$ xtensa-esp32-elf-gdb -x gdbinit myfirmware.elf

Then once in gdb, I think most of the commands are standard, however, esp32 (and most MCUs) you need to use HW break points
(gdb) hb main

[epasveer]

Thanks for the info.

[epasveer]

you need to use HW break points

I did not know that. Seer has support for HW breapoints via the "create breakpoint" dialog. However, "quick breakpoints" do not enable them by default. I suppose I can make that an option for "quick breakpoints".