From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 60969 invoked by alias); 2 Oct 2018 17:08:22 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 60960 invoked by uid 89); 2 Oct 2018 17:08:21 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=D*var, protocol, Hx-languages-length:2147 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 02 Oct 2018 17:08:20 +0000 Received: from smtp.corp.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 1B03F811A4; Tue, 2 Oct 2018 17:08:19 +0000 (UTC) Received: from [127.0.0.1] (ovpn04.gateway.prod.ext.ams2.redhat.com [10.39.146.4]) by smtp.corp.redhat.com (Postfix) with ESMTP id 6E5B52016BE2; Tue, 2 Oct 2018 17:08:18 +0000 (UTC) Subject: Re: [PATCH 1/3] Avoid find_thread_ptid with null_ptid To: Tom Tromey References: <20181001103252.5150-1-palves@redhat.com> <20181001103252.5150-2-palves@redhat.com> <87d0stll3u.fsf@tromey.com> Cc: gdb-patches@sourceware.org From: Pedro Alves Message-ID: <4a78c0f6-9d0a-2ee0-30cb-39f950f5fec5@redhat.com> Date: Tue, 02 Oct 2018 17:08:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <87d0stll3u.fsf@tromey.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2018-10/txt/msg00050.txt.bz2 On 10/01/2018 04:53 PM, Tom Tromey wrote: >>>>>> "Pedro" == Pedro Alves writes: > > Pedro> This patch prepares for the change, by avoiding passing down null_ptid > Pedro> to find_thread_ptid or to functions that naturally use it > > Should find_thread_ptid assert this? I didn't think it's useful, since the code will end up like this: struct thread_info * find_thread_ptid (ptid_t ptid) { inferior *inf = find_inferior_ptid (ptid); if (inf == NULL) return NULL; return find_thread_ptid (inf, ptid); } and null_ptid hits that assertion in: struct inferior * find_inferior_pid (int pid) { /* Looking for inferior pid == 0 is always wrong, and indicative of a bug somewhere else. There may be more than one with pid == 0, for instance. */ gdb_assert (pid != 0); But I can add it if you prefer. > > Pedro> if (print_inferior_events) > Pedro> - printf_unfiltered (_("[New inferior %d (%s)]\n"), > Pedro> - inf->num, > Pedro> - target_pid_to_str (ptid_t (pid))); > Pedro> + { > Pedro> + if (pid != 0) > Pedro> + printf_unfiltered (_("[New inferior %d (%s)]\n"), > Pedro> + inf->num, > Pedro> + target_pid_to_str (ptid_t (pid))); > Pedro> + else > Pedro> + printf_unfiltered (_("[New inferior %d]\n"), inf->num); > > I wonder if it is possible for an RSP implementation to say that the > inferior has PID 0. GDB would break down badly. Throughout we assume pid == 0 means the inferior/process is not started. The RSP docs say: "In addition, the remote protocol supports a multiprocess feature in which the @var{thread-id} syntax is extended to optionally include both process and thread ID fields, as @samp{p@var{pid}.@var{tid}}. The @var{pid} (process) and @var{tid} (thread) components each have the format described above: a positive number with target-specific ^^^^^^^^^^^^^^^^^ interpretation formatted as a big-endian hex string, literal @samp{-1} to indicate all processes or threads (respectively), or @samp{0} to ^^^^^^^^^^^^^^ indicate an arbitrary process or thread. Specifying just a process, as ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Thanks, Pedro Alves