thread-id interpreted and sent to gdb as signed int

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

Start by reproducing the remote GDB session and tracing thread IDs from the qfThreadInfo response to packets such as T and Hg. Verify where the ID changes from unsigned hexadecimal to a signed representation; done means all affected packets send the positive, protocol-compliant hexadecimal thread ID.