[Bug gdb/34316] New: Thread IDs received from remote are truncated to signed 32-bit integers

https://sourceware.org/bugzilla/show_bug.cgi?id=34316

            Bug ID: 34316
           Summary: Thread IDs received from remote are truncated to
                    signed 32-bit integers
           Product: gdb
           Version: 17.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: gdb
          Assignee: unassigned at sourceware dot org
          Reporter: jmatyas at codasip dot com
  Target Milestone: ---

Created attachment 16791
  --> https://sourceware.org/bugzilla/attachment.cgi?id=16791&action=edit
Screenshot of the gdb-remote communication with key items marked

While tinkering with FreeRTOS support in OpenOCD, I noticed that GDB truncates
(clips) the thread IDs, reported by the GDB remote server (OpenOCD) in the XML
response to qXfer:threads:read, to signed 32-bit integers.

For instance, if GDB remote client (in my case OpenOCD) sends a thread ID
"0x80082a70" in the XML, the GDB debugger appears to internally clip the value
to int32_t, and then it incorrectly uses number "-7ff7ca10" in the Hg packet.

This is obviously a bug, as the GDB Remote protocol specification [1] says:
"Several packets and replies include a thread-id field to identify a thread.
Normally these are positive numbers with a target-specific interpretation,
formatted as big-endian hex strings. A thread-id can also be a literal ‘-1’ to
indicate all threads, or ‘0’ to pick any thread."

The GDB remote communication that I observed looks like this:

Received from GDB: $qXfer:threads:read::0,1000#95

Sent to GDB:

$l<?xml version="1.0"?>
<threads>
<thread id="800832f0" name="IDLE">Name: IDLE, State: Running</thread>
<thread id="80082a70" name="Tx">Name: Tx</thread>
<thread id="800835f0" name="Tmr Svc">Name: Tmr Svc</thread>
<thread id="800819f0" name="Rx">Name: Rx</thread>
</threads>
#c3

Received from GDB: $Hg-7ff7d590#18

Please see the attached capture of the GDB Remote traffic: 

- screenshot with the key packets marked, and
- the whole traffic capture (.pcapng file that can be viewed in Wireshark)

I have tried two versions of GDB and was able to reproduce the issue in both:

- Pre-built RISC-V GDB 15.2 from
https://xpack-dev-tools.github.io/riscv-none-elf-gcc-xpack/blog/2025/10/23/riscv-none-elf-gcc-v15-2-0-1-released/

- Latest released GDB 17.2, built from source on RHEL 8 amd64 machine using the
"native" GCC 8.5.0 toolchain from the RHEL 8 distribution.

I am sorry for not having a more easy way of reproducing since I uncovered the
bug using unfinished local modifications in the OpenOCD. Nevertheless, the
attached traffic capture should be sufficient to clearly demonstrate the issue.

Please let me know if I can help of provide further information.

Details of my OS (in case it is of relevance):

$ cat /etc/redhat-release 
Red Hat Enterprise Linux release 8.10 (Ootpa)
$ uname -a
Linux <HOSTNAME_CENSORED> 4.18.0-553.56.1.el8_10.x86_64 #1 SMP Mon Jun 2
12:33:13 EDT 2025 x86_64 x86_64 x86_64 GNU/Linux

Build steps that I utilized when building GDB 17.2 from source (in case it is
relevant):

cd /tmp
wget https://sourceware.org/pub/gdb/releases/gdb-17.2.tar.gz
tar xvf gdb-17.2.tar.gz 
cd gdb-17.2/
mkdir build && cd build
../configure   --target=riscv32-unknown-elf   --disable-werror   --with-expat  
--prefix=/opt/riscv-gdb
make -j20
sudo make install
/opt/riscv-gdb/bin/riscv32-unknown-elf-gdb --help


[1] https://sourceware.org/gdb/current/onlinedocs/gdb.html/Packets.html#Packets

-- 
You are receiving this mail because:
You are on the CC list for the bug.