From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31479 invoked by alias); 24 Oct 2014 20:38:45 -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 31468 invoked by uid 89); 24 Oct 2014 20:38:44 -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-oi0-f74.google.com Received: from mail-oi0-f74.google.com (HELO mail-oi0-f74.google.com) (209.85.218.74) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Fri, 24 Oct 2014 20:38:42 +0000 Received: by mail-oi0-f74.google.com with SMTP id v63so231680oia.1 for ; Fri, 24 Oct 2014 13:38:40 -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=Gl9CScNHJmAKXqz68uVKHGb+km3Ls0t0VOwKVC+CGR0=; b=LD0KxJ6AHXyx70x7sFv5DZiGzPjCVdngasYx8JeIhg0Of4AQHdfnK0KiD7q1M01FOj uzfwBPtGKSNrhcfoDcFeA4kA4wx2zNpV9zK7PYO5BDJS2uhVaDdxBZHrOG8msEgsp+0r CnqiK2Szgf1V3d8GTRBHciQlGeDE0aevgBFENCSbUts99x854lOj+N/Br8jVxH4tBjX6 RxGLMQ3JLW8i4gXJgGyH9AB0v20i++Oz3MutwoR2yuGStqXumu9jvSmYrU6jptqvvm0q TCLTMAs3O3LZBkYBFFAAAx0OPL2uWLDiPFM9pAQX0oLtnlO1XYibYdHmM7ydQtTg13HU fe7Q== X-Gm-Message-State: ALoCoQkmNZJrBqxk5FV3HbkH2SWl3wn+aO/8aDc5O760kkirCxUwWMShDXE0zq57TkFURWeAELmbO/2qgRyLpoolKzY9SOQhGd2m91JiD85F+Za8pmk6P7B/fkhbZJmEkEuorD7S0I8a+EhaPw4PnxfqbyrDDcnVyFTVpkxdjfWipMOtuQMhwrE= X-Received: by 10.182.165.104 with SMTP id yx8mr8810424obb.15.1414183120847; Fri, 24 Oct 2014 13:38:40 -0700 (PDT) Received: from corpmail-nozzle1-1.hot.corp.google.com ([100.108.1.104]) by gmr-mx.google.com with ESMTPS id n24si307475yha.6.2014.10.24.13.38.40 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 24 Oct 2014 13:38:40 -0700 (PDT) Received: from ruffy.mtv.corp.google.com ([172.17.128.44]) by corpmail-nozzle1-1.hot.corp.google.com with ESMTP id FtH5FJkk.1; Fri, 24 Oct 2014 13:38:40 -0700 From: Doug Evans MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21578.47311.671976.969985@ruffy.mtv.corp.google.com> Date: Fri, 24 Oct 2014 20:38: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: <544AB48A.9080503@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> <21578.45122.246973.309386@ruffy.mtv.corp.google.com> <544AB48A.9080503@redhat.com> X-IsSubscribed: yes X-SW-Source: 2014-10/txt/msg00676.txt.bz2 Pedro Alves writes: > > Not all targets use ptid.lwp. > > All process_stratum targets do. windows-nat.c doesn't (at least I remember seeing all calls to ptid_build there passing 0 for lwp). Could be missing something of course. > 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. The language in the comment in ptid.h waffles a bit: process_stratum targets that handle threading themselves should prefer using the ptid.lwp field, leaving the ptid.tid field for any thread_stratum target that might want to sit on top. Can we make this more of a rule than just a "should prefer"? [and fix targets to follow]