[Bug remote/14314] New: PID read as ULONGEST but written as int

["obilaniu at yahoo dot com" <sourceware-bugzilla@sourceware.org>]

http://sourceware.org/bugzilla/show_bug.cgi?id=14314

             Bug #: 14314
           Summary: PID read as ULONGEST but written as int
           Product: gdb
           Version: unknown
            Status: NEW
          Severity: normal
          Priority: P2
         Component: remote
        AssignedTo: unassigned@sourceware.org
        ReportedBy: obilaniu@yahoo.com
    Classification: Unclassified


In remote.c, there is a mismatch in the way the remote protocol reads and
writes PTIDs in the functions write_ptid() and read_ptid().


- In read_ptid(), both the PID and the TID are declared and read as ULONGEST
(64-bit?).
- In write_ptid(), the PID is declared a (signed, 32-bit?) int and the TID is
declared a (signed, 64-bit?) long, but are written with xsnprintf() as unsigned
hex integers.


This asymmetry causes a problem on remote targets where there exists a PID (or
TID) larger than or equal to 2^31 (2^63). In that case, GDB will read correctly
the PID (TID) from the qxThreadInfo exchange, but when using the T packet to
later verify the existence of the PID (TID), instead of querying with the true
ID, it's two's complement is sent. This leads to gdbstub replying with E01 that
such a thread ID does not exist, and when subsequently GDB queries for what
threads do exist, it "rediscovers" the PID (TID) even though it was always
there.



Proposed solutions:
- Short-term: Repair write_ptid() by declaring both PID and TID to be ULONGEST
and replacing the xsnprintf() format specifier "%x" by "%lx".

- Long-term: Widen ptid_t 's PID field to a long-size integer. Also widen the
return type of ptid_get_pid(), ptid_build(), etc. accordingly.


The reason why high-valued PIDs and TIDs may exist is that on some systems, the
integer identifier is in fact a cast pointer to its (malloc-ed) block.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.