thread-id interpreted and sent to gdb as signed int

Inizia riproducendo la session GDB remota e tracciando gli ID dei thread dalla risposta qfThreadInfo fino a pacchetti come T e Hg. Verifica dove l’ID cambia da una rappresentazione esadecimale senza segno a una rappresentazione con segno; il lavoro è completato quando tutti i pacchetti interessati inviano l’ID esadecimale positivo del thread conforme al protocollo.

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