From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28287 invoked by alias); 7 Nov 2014 12:21:13 -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 28274 invoked by uid 89); 7 Nov 2014 12:21:12 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_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, 07 Nov 2014 12:21:11 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id sA7CL68o027772 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 7 Nov 2014 07:21:06 -0500 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id sA7CL4Pl024218; Fri, 7 Nov 2014 07:21:05 -0500 Message-ID: <545CB930.3040305@redhat.com> Date: Fri, 07 Nov 2014 12:21: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: Nick Bull , gdb-patches Subject: Re: [PATCH v7] Events when inferior is modified References: <5419C597.4000300@gmail.com> <542C3F4D.70104@redhat.com> <5441432B.5040103@gmail.com> <21569.29405.219428.940000@ruffy.mtv.corp.google.com> <544A6CB6.4080500@redhat.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2014-11/txt/msg00132.txt.bz2 On 11/06/2014 06:19 PM, Doug Evans wrote: > On Fri, Oct 24, 2014 at 8:13 AM, Pedro Alves wrote: >> On 10/17/2014 08:49 PM, Doug Evans wrote: >>> Alas our use of thread ids is a bit, umm, confusing >>> (in more ways than one! :-(). >>> Here, it's not guaranteed that ptid.lwp has something useful, >>> and it may be that the target uses ptid.tid instead. >>> >>> See python/py-infthread.c:thpy_get_ptid. >>> I think we should make that non-static and use that here. >>> IOW, pass the whole ptid_t to the event. >> >> How about using GDB's own unique thread number instead of >> the ptid? Doesn't seem to be any reason to expose >> target-side details or identifiers here? > > Yeah, I thought of that. > We already expose ptids. OOC, is that just py-infthread.c:thpy_get_ptid, or elsewhere too? > Plus one can look at them as just an id: something you receive, pass > around, and print. Yes, as long as we pass the whole ptid, that works. Let's go with that. > But I don't have a strong preference, other than consistency. > Whatever we pick we need to use it for everything (barring compelling > reasons to do otherwise). > > Setting aside concerns of exposing target details, > are there other technical reasons to prefer one over the other? I'm been trying to come up with some rule, but it's very hard to say in general. I was thinking that given that we're specifically referring to a user-visible thread, we should prefer the GDB number, like we generally expose GDB thread numbers to MI. But maybe we'll find a case in the future where we do an infcall on some execution object that isn't mapped to a visible GDB thread, and so a ptid would work better. > Here's a question that comes to mind. > Internally we use ptids and not thread numbers. GDB didn't use to model non-threaded inferiors as single-threaded. Until pthreads or similar was detected as loaded in the inferior, "info threads" would came out empty. So there's that historical part. (Related, I sometimes wonder about whether we should expose execution objects finer than "standard" threads, like fibers / lightweight execution agents (c++ N3874) / coroutines to the user as first class "GDB threads", if the runtime has those, thus think of "GDB threads" as the finer execution object type the user can interact with. Or maybe that's not the best model, and exposing "fibers" as first class citizens distinct from "threads" would be better.) On the target/backend/core run control side, we need to work with ptids, as we're interfacing with the lower debug APIs, which of course now nothing about GDB's thread ids, and sometimes need to interface with execution objects even if there's no GDB thread mapped to it, yet, or ever. > Do any of the reasons for doing so carry over to the Python API? I guess it depends on which level we're positioning the Python API. If at the same level as CLI/MI, and/or directly exposing the user-visible objects/concepts, then GDB ids seems preferable. Otherwise, if working at lower levels, a ptid may be better. Anyway. To reiterate, I agree. If we're just looking at the (whole) ptid as just an id: something you receive, pass around, and print, then it works for me. > > [While IWBN if internal and external APIs used the same id everywhere, > I'm more concerned with more technical details of picking one over the > other. E.g., Thread IDs are more transient, they get recycled more > often, but technically ptids can get recycled too.] Thanks, Pedro Alves