From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11540 invoked by alias); 24 Oct 2014 20:52:12 -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 11529 invoked by uid 89); 24 Oct 2014 20:52:11 -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-vc0-f202.google.com Received: from mail-vc0-f202.google.com (HELO mail-vc0-f202.google.com) (209.85.220.202) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Fri, 24 Oct 2014 20:52:10 +0000 Received: by mail-vc0-f202.google.com with SMTP id hy4so17382vcb.5 for ; Fri, 24 Oct 2014 13:52:08 -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=eKf1ZCPGXdWrMbNfuPqNgJWDwj0hKSL0i8hqdm8J528=; b=fKEKO+gs0ssyWV0hnwU7HQ3qT09fXb2yxdQyp4xKRJMXBV7qapudiRyIrFbT4FXD76 FigghdSt/Gimtuxy+kStvzg1k7ZjXY2rpaVAffp7rmiX2yZ6O/XgiY8WIGIFUAvlwaYQ icBCD/VSo4lxxBQV8gYx5z7kNqvxTGFugkKV65k/Itluu0vEJO3yL8cp3hbZElZHdHow 3iWZ/+VNo8n9aj4Jy09kIrgzTjXN5FpIIETIglks+4qZEazJ+wJfrEQUiHDmH6S9uA/d L5bdYvam1wUHyAj9YLNJ07/vjsTb740VlwgHtsCmETrq0Ft2eBP8dE9QNnGdU9uB7dz9 cW1g== X-Gm-Message-State: ALoCoQnq/W3dgDTduAFjwLI3NJQG8rMg0R8ftfU4pD71VjuJLhWP73RsYO9oXK3Oxh2VH6eRwO7jHb0lmVQLuRXCiwPKAyEC7A6htKp80RIV677wsiyuJyBvTsVV0Dd0AQvfNpWfAtUW2g2PZFabUF8S0jVVZcLfqCv9TQIs8J0S0fjO2vyJPvc= X-Received: by 10.236.105.145 with SMTP id k17mr9169278yhg.12.1414183928165; Fri, 24 Oct 2014 13:52:08 -0700 (PDT) Received: from corpmail-nozzle1-2.hot.corp.google.com ([100.108.1.103]) by gmr-mx.google.com with ESMTPS id e24si309887yhe.3.2014.10.24.13.52.07 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 24 Oct 2014 13:52:08 -0700 (PDT) Received: from ruffy.mtv.corp.google.com ([172.17.128.44]) by corpmail-nozzle1-2.hot.corp.google.com with ESMTP id X540Wsn5.1; Fri, 24 Oct 2014 13:52:08 -0700 From: Doug Evans MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21578.48118.995262.151904@ruffy.mtv.corp.google.com> Date: Fri, 24 Oct 2014 20:52:00 -0000 To: Pedro Alves cc: Sandra Loosemore , gdb-patches@sourceware.org Subject: Remove libthread_db -> remove thread_stratum? [was Re: Cannot execute this command without a live selected thread.] In-Reply-To: <21578.47311.671976.969985@ruffy.mtv.corp.google.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> <21578.47311.671976.969985@ruffy.mtv.corp.google.com> X-IsSubscribed: yes X-SW-Source: 2014-10/txt/msg00677.txt.bz2 [note subject change] Doug Evans writes: > 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] Oh, btw, another question I've been wanting to ask ... One goal we have is to remove libthread_db on linux. There are two reasons we still have it, pthread_t and thread local vars, though those can be solved. Long term, at least in linux-land, do we still want to keep thread_stratum? Knowing the answer to this will help save some typing. [If one did want to remove thread_stratum for linux there's still a need to support older systems. But on future newer systems without libthread_db, what would thread_stratum look like?]