From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22187 invoked by alias); 24 Oct 2014 20:20:36 -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 22176 invoked by uid 89); 24 Oct 2014 20:20:35 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.7 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 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 (AES256-GCM-SHA384 encrypted) ESMTPS; Fri, 24 Oct 2014 20:20:34 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s9OKKTbo030491 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 24 Oct 2014 16:20:30 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s9OKKQdq025390; Fri, 24 Oct 2014 16:20:27 -0400 Message-ID: <544AB48A.9080503@redhat.com> Date: Fri, 24 Oct 2014 20:20:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: Doug Evans CC: Sandra Loosemore , gdb-patches@sourceware.org Subject: Re: Cannot execute this command without a live selected thread. 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> <21578.45122.246973.309386@ruffy.mtv.corp.google.com> In-Reply-To: <21578.45122.246973.309386@ruffy.mtv.corp.google.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2014-10/txt/msg00675.txt.bz2 On 10/24/2014 09:02 PM, Doug Evans wrote: > 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. All process_stratum targets do. remote.c is a process_stratum target, and I think that last to be converted: commit ba3481708d3f18e77ab6c000385b131c76d2733e Author: Pedro Alves AuthorDate: Wed Feb 19 18:25:40 2014 +0000 Commit: Pedro Alves CommitDate: Wed Feb 19 18:25:40 2014 +0000 remote.c: Use the ptid.lwp field to store remote thread ids rather than ptid.tid. From GDB's perspective, independently of how the target really implements threads, gdb/remote sees all threads as if kernel/system threads. A rationale along theses lines led to gdbserver storing thread ids in ptid.lwp in all ports. Because remote.c is currently using ptid.tid, we can't make gdbserver and gdb share bits of remote-specific code that manipulates ptids (e.g., write_ptid/read_ptid). This patch thus makes remote.c use ptid.lwp instead of ptid.tid. I believe that on the GDB side too, it's best that we standardize on process_stratum targets using the ptid.lwp field to store thread ids anyway. The idea being leave the ptid.tid field free for any thread_stratum target that might want to sit on top. > Does remote.c not support targets that use tid instead of lwp? > I guess not. Not sure what you mean by "support" here. Thanks, Pedro Alves