From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6155 invoked by alias); 24 Oct 2014 20:02:15 -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 6144 invoked by uid 89); 24 Oct 2014 20:02:14 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-ob0-f201.google.com Received: from mail-ob0-f201.google.com (HELO mail-ob0-f201.google.com) (209.85.214.201) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Fri, 24 Oct 2014 20:02:13 +0000 Received: by mail-ob0-f201.google.com with SMTP id nt9so215278obb.0 for ; Fri, 24 Oct 2014 13:02:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:mime-version:content-type :content-transfer-encoding:message-id:date:to:cc:subject:in-reply-to :references; bh=jm9L8K5cOpHTurno6SncI81n7mh69itwEjSPqg+q0IQ=; b=B4yMX3GbUEHiNicwckTFMOItIUCJ8P3UXp5+azbAdN6sInPze2hTsxZLUsyJGaCvlI QAaxC8zE6vrAPhe+TEjU6FEr7bj73XSHCCc0/XZwtonlAQhEJgNRUj9Q6yMn/hPPD6B1 KvxixM+RPrUPMTKd/+JwHdIWusN2xBSzOnCn/plAo3zTKjSorT+DT6UXvdYb7FJYD0Be OzXeOv0uLof/bp5eIiUczQ0LQU8lOwDnm0nSXWw/8XbT1I+a38DX1KMg1lvOeXD9F6L0 u8PCwEefVqfxd8r2Ll2PdXKgksx4LTqFYov8Jj7EmCLdumFqoWGr6A3ql8QYmuAcw231 EEzA== X-Gm-Message-State: ALoCoQnfoKQq78HzOg5dQca7rt06gGoAOP5cFSjuOGW6f6AEsKZdXtpn1GBWQikj3f8w8CKshdbr9eMquIDv4bIHxgMJOwfT+Lwl5Tc2wGasz3C8ZdMNkcFg5nWqBcgT6MUpKpWbdeeNPmpryT6EaeTwXw+ZhhEuTRtoGZWj9A7zsPJCoBWFFoI= X-Received: by 10.42.94.202 with SMTP id c10mr13700369icn.12.1414180931435; Fri, 24 Oct 2014 13:02:11 -0700 (PDT) Received: from corpmail-nozzle1-1.hot.corp.google.com ([100.108.1.104]) by gmr-mx.google.com with ESMTPS id k66si302810yho.7.2014.10.24.13.02.10 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 24 Oct 2014 13:02:11 -0700 (PDT) Received: from ruffy.mtv.corp.google.com ([172.17.128.44]) by corpmail-nozzle1-1.hot.corp.google.com with ESMTP id wHJBlo9i.1; Fri, 24 Oct 2014 13:02:11 -0700 From: Doug Evans MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21578.45122.246973.309386@ruffy.mtv.corp.google.com> Date: Fri, 24 Oct 2014 20:02:00 -0000 To: Pedro Alves Cc: Sandra Loosemore , gdb-patches@sourceware.org Subject: Re: Cannot execute this command without a live selected thread. In-Reply-To: <544AAB39.4030503@redhat.com> References: <544A7648.6060102@codesourcery.com> <544A7930.4040909@redhat.com> <544A8741.9090705@codesourcery.com> <544A8B0C.5000509@redhat.com> <544A8F15.9000906@redhat.com> <21578.42546.658345.633154@ruffy.mtv.corp.google.com> <544AAB39.4030503@redhat.com> X-IsSubscribed: yes X-SW-Source: 2014-10/txt/msg00673.txt.bz2 Pedro Alves writes: > On 10/24/2014 08:19 PM, Doug Evans wrote: > > > I looked at the current remote_thread_alive. > > It has this: > > > > if (ptid_get_pid (ptid) != 0 && ptid_get_lwp (ptid) == 0) > > /* The main thread is always alive. This can happen after a > > vAttach, if the remote side doesn't support > > multi-threading. */ > > return 1; > > > > pid != 0 && lwp == 0 -> main thread? > > That sounds odd. > > Do you know why the test is the way it is? > > If it's the 0 part you're calling out as odd, it's that way > because we didn't have a thread id back when we created > the thread: > > static void > extended_remote_attach_1 (struct target_ops *target, const char *args, > int from_tty) > { > struct remote_state *rs = get_remote_state (); > int pid; > char *wait_status = NULL; > > pid = parse_pid_to_attach (args); > > ... > set_current_inferior (remote_add_inferior (0, pid, 1)); > > inferior_ptid = pid_to_ptid (pid); > > ... > { > /* Now, if we have thread information, update inferior_ptid. */ > inferior_ptid = remote_current_thread (inferior_ptid); > > /* Add the main thread to the thread list. */ > add_thread_silent (inferior_ptid); > } > ... > > > Later on, when we get the first stop event back, we may or may not > find a thread id to use: > > static void > remote_notice_new_inferior (ptid_t currthread, int running) > { > ... > if (ptid_is_pid (inferior_ptid) > && pid == ptid_get_pid (inferior_ptid)) > { > /* inferior_ptid has no thread member yet. This can happen > with the vAttach -> remote_wait,"TAAthread:" path if the > stub doesn't support qC. This is the first stop reported > after an attach, so this is the main thread. Update the > ptid in the thread list. */ > if (in_thread_list (pid_to_ptid (pid))) > thread_change_ptid (inferior_ptid, currthread); > else > { > remote_add_thread (currthread, running); > inferior_ptid = currthread; > } > return; > } > > If we never see any stop reply with a thread id, or the target > doesn't support any thread listing packets, it must be that the > target doesn't really support threads, so we shouldn't ever delete > that thread, for we made it up. We use "pid != 0 && lwp == 0" > rather than magic_null_ptid as the former carries more info, for > including the PID that the user specified on "attach PID" (and a stop > reply with a thread id may come along), so we can put that PID in > inferior->pid too and display it in "info inferiors", etc., and preserve > the invariant that starting from a ptid we can find the corresponding > inferior, matching by pid. We shouldn't ask the target whether > that thread is alive, as it's a thread id we made up. > > BTW, we do the same in native debugging. E.g., see inf-ptrace.c: > > inferior_ptid = pid_to_ptid (pid); > > /* Always add a main thread. If some target extends the ptrace > target, it should decorate the ptid later with more info. */ > add_thread_silent (inferior_ptid); > > If the inferior is truly non-threaded, and doesn't have any other > threads, it's main/single thread can well end up with a ptid with only > the pid field set; there's no conflict with using (pid,0,0) to refer > to all threads of the process as there'll be only one in that > process anyway. Thanks, that's helpful. Not all targets use ptid.lwp. Does remote.c not support targets that use tid instead of lwp? I guess not.