From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 3AMwCis7RmrwTCIAWB0awg (envelope-from ) for ; Thu, 02 Jul 2026 06:19:23 -0400 Received: by simark.ca (Postfix, from userid 112) id 1ABA01E098; Thu, 02 Jul 2026 06:19:23 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-5.3 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED autolearn=ham autolearn_force=no version=4.0.1 Received: from vm01.sourceware.org (vm01.sourceware.org [38.145.34.32]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 11B531E024 for ; Thu, 02 Jul 2026 06:19:22 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 916654BA23EB for ; Thu, 2 Jul 2026 10:19:20 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 916654BA23EB Received: from gnu.wildebeest.org (gnu.wildebeest.org [45.83.234.184]) by sourceware.org (Postfix) with ESMTPS id 043914BA2E33 for ; Thu, 2 Jul 2026 10:18:57 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 043914BA2E33 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=klomp.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=klomp.org ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 043914BA2E33 Authentication-Results: sourceware.org; arc=none smtp.remote-ip=45.83.234.184 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1782987537; cv=none; b=olvpZmQZeu4pvq43MjVEfjWUh/x9InqfRgDKYfFaD1gTLO3pkAUPAhq+NE0UUWuPsGz58W6UPsE786/PdvxNjX6+eDtQ6gv83l7zuXGgFzM8n1UJwYkgg1c0RBykc5Evc1izh8XfAD6aeXPqs9VqyPcWqY4B046om94uV5OG3mA= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1782987537; c=relaxed/simple; bh=FdY8znhjg+Hy22VYD/7VVsZGlfezGUQS5JVpRunb9JQ=; h=Date:From:To:Subject:Message-ID:MIME-Version; b=T64hTV3g+5wHbdkrtSfpycKYMeZJOBxB2qiXsZRWeZu3lR0kQ/CRJvf/Mkh+f3EU8f9EgV8vjZCZXi66hWKyRXv9QqPTCNZH3LvCFTfk327Zbn47nZ25ZSGmQdAK1a7NrMlrLdLhjfcuUc4B00PDZK4M7OdG2ike3FsjgvoV9Xw= ARC-Authentication-Results: i=1; sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 043914BA2E33 Received: by gnu.wildebeest.org (Postfix, from userid 1000) id 0069B30132F4; Thu, 2 Jul 2026 12:18:55 +0200 (CEST) Date: Thu, 2 Jul 2026 12:18:55 +0200 From: Mark Wielaard To: Tom Tromey Cc: gdb-patches@sourceware.org Subject: Re: [PATCH] Do not write negative PID or TID in remote protocol Message-ID: <20260702101855.GI4673@gnu.wildebeest.org> References: <20260430175904.1342455-1-tromey@adacore.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260430175904.1342455-1-tromey@adacore.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces~public-inbox=simark.ca@sourceware.org Hi Tom, On Thu, Apr 30, 2026 at 11:59:04AM -0600, Tom Tromey wrote: > Currently both gdb and gdbserver can write a negative number for the > PID or TID. However, the only negative value that really makes sense > is the special case of "-1" -- in other cases if the PID or TID has > the high bit set, it should still be written as a positive number. > > This patch attempts to fix the bug. > > v2 of this patch combines the implementations and moves them to > gdbsupport. I tried making these standalone functions in rsp-low.cc, > but that runs afoul of libipa. So, I made them methods of ptid_t. > > The new unit tests pointed out that round-tripping a sign-extended > number didn't really work, because the checks were done via ULONGEST. > It's kind of unfortunate that the PID and LWP are host-dependent > types. This should probably be fixed, but I haven't done so here. > Meanwhile I changed the checks to use the corresponding unsigned type. It looks like there is still something wrong on 32bit arches. At least after this patch the i386 debian buildbot fails: https://builder.sourceware.org/buildbot/#/builders/105/builds/12989 > +ptid_t > +ptid_t::parse (const char *buf, const char **obuf, bool for_remote, > + gdb::function_view default_pid) > +{ > + const char *p = buf; > + const char *pp; > + ptid_t::pid_type pid = 0; > + ptid_t::lwp_type lwp = 0; > + ULONGEST hex; > + > + using unsigned_pid_type = std::make_unsigned::type; > + using unsigned_lwp_type = std::make_unsigned::type; > + > + if (*p == 'p') > + { > + /* Multi-process ptid. */ > + pp = unpack_varlen_hex (p + 1, &hex); > + if (pp == (p + 1) || *pp != '.') > + error (_("invalid remote ptid: %s"), buf); > + > + pid = (ptid_t::pid_type) hex; > + if (hex != ((unsigned_pid_type) pid)) > + error (_("invalid remote ptid: %s"), buf); > + > + p = pp + 1; > + hex = hex_or_minus_one (p, &pp, for_remote); > + if (pp == p) > + error (_("invalid remote ptid: %s"), buf); > + > + lwp = (ptid_t::lwp_type) hex; > + if (hex != ((unsigned_lwp_type) lwp)) > + error (_("invalid remote ptid: %s"), buf); Are the types/castes here correct? hex is an ULONGEST that is being cast to an ptid_t::lwp_type and then an unsigned_lwp_type. Then this sanity check seems to fail (on i386 at least). I think this is because ULONGEST on i386 is unsigned long long, while unsigned_lwp_type is unsigned long. Cheers, Mark