thread-id interpreted and sent to gdb as signed int

Beginne damit, die Remote-GDB-Sitzung zu reproduzieren und die Thread-IDs aus der qfThreadInfo-Antwort bis zu Paketen wie T und Hg nachzuverfolgen. Überprüfe, an welcher Stelle sich die ID von einer vorzeichenlosen hexadezimalen Darstellung in eine vorzeichenbehaftete Darstellung ändert; abgeschlossen ist die Aufgabe, wenn alle betroffenen Pakete die positive, protokollkonforme hexadezimale Thread-ID senden.

Environment

• OS and version: Debian 12
• VS Code: 1.95
• C/C++ extension: v1.22.10
• OS and version of remote machine (if applicable): n/a
• GDB / LLDB version: 13.1

Bug Summary and Steps to Reproduce

Bug Summary:
Using the vscode debugger with a remote gdb target, the thread-ids are sent on the wire as signed ints for some messages. For example:

qfThreadInfo -> m800c1568,800bf3c0,800bd218,80024f68l

Establishes 4 threads in the "Call stack' view:

• 2148275560 (800c1568)
• 2148266944 (800bf3c0)
• 2148258328 (800bd218)
• 2147635048 (80024f68)

When clicking on one of the threads in the 'call stack' view (i.e. 2148266944) a message gets sent to the remote T-7ff40c40. The message on the wire should be unsigned, but it is being sent as a signed hex. (-7ff40c40 == 800bf3c0). It should be sent as: T800bf3c0

I've seen a few other messages in the trace like this as well. For example: Hg-7ff40c40.

It looks like somewhere along the path, the thread-id is being serialized as a signed int which is against the protocol specifications.

You can see the docs, say it should be "a positive number with target-specific interpretation formatted as a big-endian hex string"

Debugger Configurations

{
"version": "0.2.0",
"configurations": [{
"name": "Attach ed64",
"type": "cppdbg",
"request": "launch",
"cwd": "${workspaceFolder}",
"program": "${workspaceRoot}/build/unflexa1.elf",
"miDebuggerServerAddress": "127.0.0.1:8080",
"miDebuggerPath": "gdb-multiarch",
"targetArchitecture": "mips",
"preLaunchTask": "unfloader",
"postDebugTask": "stop unfloader"
}]
}

Debugger Logs

Replying with 'T05swbreak:;'
RDB sent packet 'g'
Replying with '0*,0*,0*,0*)c1b07cf*"ff800bf3e80*,f*"ff80024f680*,0730*+40*,f*"ff8001eb100*+40*,0*,0*,f*"ff807ff810f*"ff807ff5e0f*"ffa460*!0*+30*"0010001d00f*"ff80024628f*"ff80* 4000*'16c180*,x*,x*,0*,f*"ff8002c558f*"ff807fffb8f*"ff807fffb80*"00241014e30*+10*,10200108300019000**24ffffffff8000ea380*"004270*!0*"003c88ee160*,0*,0*,0*,0*,0*,0*,0*,0*,0*,0*"00426f4e010*,0*,0*,0*,0*,0*,0*,0*,0*,0*,0*,0*,0*,0*,0*,0*,0*,0*,0*,0*%1001e040*&800b11'
RDB sent packet 'qfThreadInfo'
Replying with 'm800c1568,800bf3c0,800bd218,80024f68l'
RDB sent packet 'qsThreadInfo'
Replying with ''
RDB sent packet 'z0,8000e9b0,4'
Replying with 'OK'
RDB sent packet 'z0,8000ea38,4'
Replying with 'OK'
RDB sent packet 'z0,8000ea58,4'
Replying with 'OK'
RDB sent packet 'm807fffc0,40'
Replying with '00000000000000000000000000000000000000000000000000000c1b807ff810ffffffff807ff810ffffffff8000046c00000000000000000000000000000000'
RDB sent packet 'm8000046c,4'
Replying with '0800011b'
RDB sent packet 'm80000400,4'
Replying with '3c1c8003'
RDB sent packet 'm80000404,4'
Replying with '279cc558'
RDB sent packet 'm80000408,4'
Replying with '3c022410'
RDB sent packet 'm8000040c,4'
Replying with '344200e0'
RDB sent packet 'T-7ff40c40'
Replying with ''

Other Extensions

No response

Additional Information

No response