Call stack thread ids UI not refreshed with thread names after GDB command

Environment

• OS and version: Ubuntu 20.04/22.04, W10, W11. Applies to any version.
• VS Code: 1.83
• C/C++ extension: v1.17.5
• OS and version of remote machine (if applicable):
• GDB / LLDB version: Customized one.

Bug Summary and Steps to Reproduce

Bug Summary:

To debug a core dump from our target devices, we have two different data files regarding debug symbols and thread names.
Till now, all company has been using QtCreator for C++ development, but we're doing a transition to WSL2 + VSCode as the new setup. There is a modified version of GDB that has a function called map-thread-names, which as the name implies, it maps & loads the thread names dump file & associate it to the actual call stack from the Core Dump.

Well, this is done automatically with some configurations on QtCreator after you launch the Debugger: the call stack reflects accordingly the thread names. However, with VSCODE I'm able to use the customized GDB, launch the Core Dump and so on, even to run on the Debug Console the command map-thread-names and it will work but only in the Debug console context the thread IDs will be updated (map-thread-names && info threads). The Call Stack UI wont refresh or update anything after executing this command on the GDB Debug Console.

Before running map-thread-names:

After running function & show info threads. Updated on Debug Console but Call Stack UI still shows unmapped.

Debugger Configurations

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "(gdb) Launch Core Dump",
            "type": "cppdbg",
            "request": "launch",
            "program": "/mnt/disk1/app/bin/App",
            "args": ["-g "],
            "stopAtEntry": true,
            "coreDumpPath": "${workspaceFolder}/coreDump",
            "sourceFileMap": {
                "/shell": "${workspaceFolder}",
            },
            "targetArchitecture": "x64",
            "additionalSOLibSearchPath": "/mnt/disk1/app/lib",
            "cwd": "${fileDirname}",

            "miDebuggerPath":"/customgdb",
            "MIMode": "gdb",
            
            "logging": {
                "trace": true,
                "exceptions": true,
                "engineLogging":"verbose"
            }
        }
    ],
    "compounds": []
}

Debugger Logs

I would need to remove info, but can share if needed. I dont think it's relevant for this issue, however.

Other Extensions

No response

Additional Information

Shouldn't the Call Stack UI listen this & update/refresh? Is there anything that we can do to trigger a refresh in the UI to load them? If not, how difficult should be to implement an option like that for the extension?

Thanks!

Inizia riproducendo la sessione di core-dump con il GDB personalizzato, quindi confronta l'output della Debug Console di map-thread-names <file> e info threads con la Call Stack UI. Analizza il percorso di aggiornamento dei thread e della call stack dell'estensione; il lavoro è completato quando la UI riflette i nomi dei thread aggiornati dopo il comando, con una riproduzione verificata o un test di regressione.