[Bug]: Usability issues with CDT GDB Adapter and multi-client/multi-core - Part 2

[jreineckearm]

Description

Collection of some smaller issues with GDB Adapter. Some are related to the just introduced auxiliaryGdb settings. Others are there for a while already. None of them is fatal, but they look scary when seeing them for the first time:

• 1. https://github.com/Arm-Examples/cmsis-mlek-examples/tree/main/Alif/AppKit_D3/MLEK_AV_DualCore : when you build, load, and debug this, you often see warnings like this: warning: (Internal error: pc 0x8020a6d8 in read in CU, but not in symtab.), warning: (Error: pc 0x8020a6d8 in address map, but not in symtab.)
  Looks like warnings coming from GDB and could point to inconsistent debug info in the binaries. At the very minimum understand the root cause before 1.2.0 release.
  Note: So far only visible when RTOS Views is enabled, for this example RTX5.
• 2. Easy to accidentally attach to already connected start-core. This is with configurations managed by CMSIS Solution Extension where we have a launch and an attach configuration for the start-core to support both "Load & Debug" and "Load & Run" followed by belated attach. Need to investigate if we can guard connections in this case.
• 3. pyOCD multi-core launch configs normally have one launch config and one attach config for every additional core in the system. However, if you exit the launched session first, you target access with the attached connection. It may be related to trouble we have on CDT GDB Adapter level if losing a GDB server, where GDB from a certain version on no longer properly crashes. But maybe there is something connected to 5.) which can be done on top.

Some of the issues may be in viewer extensions. But the CDT GDB Adapter needs to become more robust/less noisy, too. The more views are added in future, the more traffic has to be expected and dealt with.

Steps to Reproduce

No response

Expected Behavior

No response

Additional Information

No response

[jreineckearm]

Item 1.) is about finding out if debug info is broken, or if GDB does something wrong. Also, we could try to filter out such messages from Arm CMSIS Debugger extension's debug tracker to keep the Debug Console clean. IMO, they are of no real value to our users.

Item 2.) still needs investigation.

Item 3.) also still needs investigation, no good way yet to detect we lost pyOCD under the hood.

[jreineckearm]

1.) More research: still haven't fully understood the problem or proof. But from what I understand so far (with the help of a trusted AI), the generated AC6 debug info looks sensible. However, GDB always interprets addresses for a CU in .debug_addr tables as code addresses. Including those of const variables placed inside a code section. Loading debug info for a CU then runs some checks and can't find a function entry in the symbol table while doing some cross-checks.

I don't expect us to fix this quickly at the root. Hence my proposal is:

• Use the debug tracker in CMSIS Debugger for gdbtarget to detect and discard such GDB output. It's a bit hacky, but I believe one can manipulate the Output Event` category in the tracker's event handler.
• The filter pattern can be hard-coded. But we might want to make it configurable as a CMSIS Debugger extension setting. That way it can be turned off if not wanted.
• Filtering could alternatively live as an option in CDT GDB Adapter. I am just worried about the growing amount of settings we have to pass through the launch configurations. That user visible filter list could grow over time.

Root cause/sustainable fix needs then further analysis in GDB. The above doesn't help with GDB CLI usage without VS Code.