Regarding the Implementation of the Live Watch Feature on Eclipse Embed CDT

[SnowyTulip]

1 About the Requirement for Live Watch with Eclipse Embed-CDT

Mentioned in issue:597

The goal is to implement an online debugging feature in Eclipse Embed CDT: during the debugging process, even if no breakpoint is hit, we should still be able to see the changes of debug values in the Embed CDT window.

As stated in issue:597, this is not a simple patch but a complex project. To implement it, the following problems need to be solved:

1. Enable command interaction between Eclipse Embed CDT and GDB

2. Allow GDB to send query commands while debugging without stopping execution

3. Allow debug probes (OpenOCD, J-Link, etc.) to handle memory read commands from GDB (the m packet in the RSP protocol) without stopping debugging

2 Solutions

2.1 Command Interaction Between Eclipse Embed CDT and GDB

At first glance, there seems to be an obvious solution: we could reuse Eclipse’s built-in Expressions view. This view can parse variables very well. If it provided an API to re-evaluate all variables, we might be able to set up a thread in Eclipse to periodically call the evaluation and refresh the UI.

Unfortunately, after spending a lot of effort trying to understand the behavior of Eclipse’s Expression Manager, I did not find such an interface. During debugging, it considers the target to be unavailable, preventing the execution of variable evaluation commands.

Therefore, one feasible way for Embed CDT and GDB to interact is by using CDT-related interfaces.
After obtaining the debug DSF session, using CommandControl + CommandFactory allows sending any desired commands to GDB at any time.

2.2 GDB to the Target Chip

Obviously, when GDB sends a command without hitting a breakpoint, GDB will block, which manifests as the inability to write any characters to GDB’s input stream. This behavior is the same in both GDB’s terminal mode and MI mode.
However, GDB also provides solutions: non-stop mode and asynchronous debugging.

2.2.1 Using GDB’s Non-stop Mode

Unfortunately, this method requires the debugging probe to support non-stop mode, but almost no debug probes fully support it.
Texas Instruments’ debug probe, however, does support it.
Tests have shown that J-Link, OpenOCD, and ST-Link do not support it.

https://forum.segger.com/index.php/Thread/1425-JLink-GDBServer-async-mode/?page=Thread&threadID=1425

Supporting non-stop mode seems to be a rather complex task, requiring complete RSP protocol support in the debugging probe. We may need to consider other approaches.

2.2.2 Using Asynchronous Debugging

set target-async on or gdb-set mi-async on

This method can solve the problem of sending query commands without stopping execution.

1. Protocol Confusion:
   Since non-stop mode is not fully supported, issuing an m query after continue will cause GDB to fail to recognize subsequent breakpoint hit notifications (s05 cannot be recognized by GDB as a valid response to the c packet).
   As a result, GDB will not realize the target has stopped, which means that in the IDE, after clicking Resume, the expected breakpoints will not be hit.

   According to the official GDB documentation, if non-stop mode is disabled, no other query commands are allowed between a step or continue command and the point when the target stops (reports s05 or another signal) to GDB.

   https://sourceware.org/gdb/current/onlinedocs/gdb.html/Overview.html

2. Debug Stop Requests:
   For actions like inserting breakpoints or suspending execution, the debugger’s interrupt handling logic must be reconfigured.
   The original logic is: send a Ctrl + C signal to GDB to trigger suspend, then send the breakpoint insertion request.
   However, after enabling target-async, Ctrl + C can no longer stop GDB and the target directly — you must first send interrupt -a to stop them, which requires additional handling in Eclipse’s debug backend.

3. Modifying GDB:
   In fact, if you only enable async mode without any changes, GDB will still intercept query commands.
   To work around this, you need to modify GDB’s source code by commenting out the relevant interception code.

Advantages:

• No need to start multiple GDB connections
• Not limited to OpenOCD; other debug probes can also work

Disadvantages:

• Protocol confusion issues
• Requires special handling in the debug probe

2.2.3 Starting Two GDB Debuggers

Marus/cortex-debug#810
It may sound unusual, but thinking it through, this could indeed work.

• OpenOCD can be configured via a .cfg file to support launching two GDB connections.
• In this setup, one GDB connection controls the normal debugging process, while the other is dedicated solely to sending m requests to query global variables and memory.
• From the debug probe’s perspective, it only needs to decide how to handle certain packets coming from a particular GDB instance.
• The second GDB will not reject expression evaluation commands we send to it (for global variables and static variables) because it always assumes the chip is not running. We are in a state of having just connected to the chip, so naturally, it can view any memory values.

1. Protocol Confusion:
   This issue does not occur, because the second GDB only sends m packets, and the debug probe simply responds to them.
   There’s no scenario where one GDB sends a c packet and m packets get interleaved to disrupt the protocol — all m packets go to the second GDB.

2. Debug Stop Requests:
   Not an issue here, because the GDB responsible for debugging runs in normal all-stop mode, and the GDB querying variables never sends any target-control commands.

3. No Need to Modify GDB Source Code:
   The GDB responsible for variable queries does not use any control commands and will not consider the target as running, so it can directly perform queries without issue.

Configuring OpenOCD to support multiple GDB connections seems to be possible only with OpenOCD, but OpenOCD supports a wide range of debug probes.

This is totally feasible, and I have already reproduced it

Referencing the TCL script provided by cortex-debug:

#
proc CDLiveWatchSetup {} {
    try {
        foreach tgt [target names] {
            set nConn [$tgt cget -gdb-max-connections]
            if { $nConn > 0 } {
                incr nConn
                $tgt configure -gdb-max-connections $nConn
                puts "[info script]: Info: Setting gdb-max-connections for target '$tgt' to $nConn"
            }
        }
    } on error {} {
        puts stderr "[info script]: Error: Failed to increase gdb-max-connections for current target. Live variables will not work"
    }
}

3 Demo with Starting Two GDB Debuggers

Second GDB Usage Command Sequence

• file test001.out
• target extended-remote :3333

However, it can only view global variables, static variables, and memory (which is understandable since GDB does not know which function call frame the current target is running on, so it has no way to obtain local variables. Of course, global variables are sufficiently useful).

In the image below, I am using Eclipse Embed-CDT to debug an STM32 development board. During the debugging session, I open GDB and use a second GDB instance in the terminal to connect to the OpenOCD that Eclipse is using for debugging.

It can be seen that the observation of the global variable s1 is achieved without stopping the program!!!

[SnowyTulip]

I adapted the Live Watch feature for the chips in my lab. For our chips, I use Method 2, which is an asynchronous GDB implementation.

1. The encapsulation and refresh of the data model are quite complex. The parsing process is not as simple as just querying GDB and returning results. Instead, it requires constructing variables and analyzing child items within GDB.
2. The UI implementation is relatively cumbersome.
3. This debug view also needs to maintain the debug context and the DSF session...

In the debug launch, many custom modifications and configurations are needed... At a minimum, the foundation for implementing this feature is to provide a way for Live Watch to obtain the DsfSession during the debug launch startup process.

Additionally, for the debug agent, we also made custom modifications, which can be considered as a way to avoid the protocol confusion issues.

QQ2025810-21244-HD.mp4

[SnowyTulip]

Currently, I am exploring Method 3, which involves starting two GDB instances to connect to OpenOCD to ultimately achieve the live watch feature. However, starting an additional custom session and executing a custom command sequence during the debug session startup in Eclipse is quite cumbersome.

It requires implementing a complete debug backend to provide the DsfSession, but I believe this is 100% feasible. However, it will take a significant amount of time. Maybe after I graduate with my master's degree, I will organize a code example and share it.

[fanghuaqi]

Hi, we have implement live watch via telnet port, using openocd + sba feature, see https://doc.nucleisys.com/nuclei_tools/ide/advanceusage.html#live-watch

[SnowyTulip]

Hi, @kairoaraujo
Amazing, I didn't expect there to be such an implementation. This directly queries memory from the IDE to OpenOCD via telnet. If not using gdb, how should symbols be resolved? Does the IDE need to analyze the symbol table of the executable program?