rtt: Add gdb monitor rtt down command

[HrMitrev]

Detailed description

Just for convenience I wanted to be able to
push strings to the rtt down buffer without
the need to change the active window from
the one where the gdb session is running

Your checklist for this pull request

• I've read the Code of Conduct
• I've read the guidelines for contributing to this repository
• It builds for hardware native (make PROBE_HOST=native)
• It builds as BMDA (make PROBE_HOST=hosted)
• I've tested it to the best of my ability
• My commit messages provide a useful short description of what the commits do

Closing issues

None

[HrMitrev]

Hi @koendv 🙂

Since you're the original author of the RTT functionality, could you take a quick look?

The main idea is to start the program with run & when using gdb and then I want to have .gdbinit function which sends SIGINT (interrupt) then monitor rtt down 'string' then continue &

Ideally it would be best if I there is a way to interact with the BMP probe from gdb without interrupting the debug session, but I'm not sure how and if it is even possible. Sure I can directly use ttyBmpTarg to send data to the target, but just for convenience I don't want to change the active window to the terminal where I view the log, send the string and then go back to the terminal where the gdb session is running

[dragonmux]

There are a couple of linguistic items we caught in review and some type issues. Please see below for more on those. Please also take care of the clang-format lints the CI picked up.

We're distinctly unsure whether to take this proposed change or not, being how easy it is to use a second console with a serial program to interact with the RTT stream. That said, we can also sort of see the sense of this command too. We'll see how bad the Flash usage hit is after the adjustments requested and have a chat with Esden.

[koendv]

On Mon, 18 Dec 2023 09:06:36 -0800 Hristo Mitrev ***@***.***> wrote: Hi @koendv 🙂 Since you're the original author of the RTT functionality, could you take a quick look?

Hi Hristo. This also works: ^C Program received signal SIGINT, Interrupt. 0x08000528 in ?? () (gdb) python rtt = open("/dev/ttyBmpTarg", "w") (gdb) python rtt.write("hello, world") (gdb) python rtt.flush() (gdb) c Continuing. I'm wondering: If you send data, maybe you'll want to wait for some kind of reply. Like the linux "expect" command, or python pexpect. koen

[HrMitrev]

Hi Hristo. This also works: ^C Program received signal SIGINT, Interrupt. 0x08000528 in ?? () (gdb) python rtt = open("/dev/ttyBmpTarg", "w") (gdb) python rtt.write("hello, world") (gdb) python rtt.flush() (gdb) c Continuing. I'm wondering: If you send data, maybe you'll want to wait for some kind of reply. Like the linux "expect" command, or python pexpect. koen

Hi @koendv,

This is a great suggestion, but I am afraid that my use-case is a bit different.
I always have /dev/ttyBmpTarg open in another console because I need to save the logs to a file and also look at them in the meantime. My main idea was to skip the need of switching from gdb to the log console in order to send commands. Since I have to have /dev/ttyBmpTarg open in another window I thought that this gdb mon command will be helpful.

PS: it took me a while to realize that there are 2 separate rtt_if.c files for stm32 and launchpad-icdi. I think I fixed the problem and it seems that all the tests now pass. I also rebased to the latest commit in main

[koendv]

I think an rtt "send" command might be useful as a first step towards making testbenches in gdb/python.

[HrMitrev]

Hi Again!
If I remember correctly, the overhead of this feature was 72 more bytes of ROM.

Since I proposed this enhancement I also realized that it will be helpful when I implement a make-shift password that will be used to lock some debug features of the target. If I implement such password it will be tedious to enter it every time I flash my target. Having this feature will help to automate this. (I thought of this password because I give debug versions of my firmware to testing colleagues who provide me with logs, but the problem is that I also implement "scanf actions" that can alter the internal state of the program and lead to false positive bug reports)

One more proposal from my side will be to add ifdef guards and make this optional if we think that it will add too much overhead.

Cheers!