From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 993AD3858406; Sun, 7 Nov 2021 08:04:16 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 993AD3858406 From: "fredrik.hederstierna@securitas-direct.com" To: gdb-prs@sourceware.org Subject: [Bug remote/25111] [Zephyr/thread aware debugging] remote: write_ptid returns negative tid. Date: Sun, 07 Nov 2021 08:04:16 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gdb X-Bugzilla-Component: remote X-Bugzilla-Version: 8.3.1 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: fredrik.hederstierna@securitas-direct.com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: gdb-prs@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-prs mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Nov 2021 08:04:16 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D25111 Fredrik Hederstierna changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fredrik.hederstierna@securi | |tas-direct.com --- Comment #1 from Fredrik Hederstierna --- When looking into Zephyr and OpenOCD I just saw this ticket. Isn't there a discrepancy in for ptid_t write/read when it comes to types.= The 'lwp' is used as 'tid', but has a wider type: int ptid_get_pid (ptid_t ptid) long ptid_get_lwp (ptid_t ptid) long ptid_get_tid (ptid_t ptid) so in the it reads into ULONGEST, which I guess is uint64_t, but the instead implicit cast long to int when using 'lwp as 'tid' (which I believe is often int32_t on a normal host target machine): int tid; tid =3D ptid.lwp (); Wouldn't it be better to keep the wider long type, and keep calling 'tid' f= or 'lwp' which it actually is? And also keeping the long-type in the write function? In this case there won't be any overflow if an 32bit int represen= ting 'tid' is becoming >0x80000000. The read function I guess will still handle = it as it is using ULONGEST to my understanding. Attaching idea of a possible patch. --=20 You are receiving this mail because: You are on the CC list for the bug.=