From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27162 invoked by alias); 7 Nov 2014 17:04:53 -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 27149 invoked by uid 89); 7 Nov 2014 17:04:52 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.2 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-qa0-f51.google.com Received: from mail-qa0-f51.google.com (HELO mail-qa0-f51.google.com) (209.85.216.51) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Fri, 07 Nov 2014 17:04:51 +0000 Received: by mail-qa0-f51.google.com with SMTP id f12so2597976qad.10 for ; Fri, 07 Nov 2014 09:04:49 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=jvAyJxULvjjOOnwo7fRnhz079hzbEFKceezz5wmRHZM=; b=EbplwxLpP/uP7wpKXdNgrx5kndnDFppvNjC1G1wHFanbLGIRcke8sE2Hq8KZW3TG27 aQwEgtC7dcxjYphWyNAic7ggH+LdQLn1Lez8yIw3QNyJrk9yCfTuC/EIdCLJ+jRkJzrN oaG+pkd0ydNtOFqJkGSaUxApSd2Xv3EpmV1O33+QbdB6EE/2TDpV++Xh8SGk9wcHHSjV 0YHddzmsAuThaygjEfJ5SEDRyybXq5+Iav8epAHWSVf7r+3VcEnRr/YmpsB85xl6bmp0 NfeMhx22Jbf3rESPsG+8XvjKhfFIDssh9G9sp9/x8OPbFvfRJl37sp2cGmwAW06d2yzX LexA== X-Gm-Message-State: ALoCoQmnuYlc1J1g3Y+BDSLdYimNxozhgzSF+Rh7RDKODXvCTFiwSqTBoeqpzUMmahhz2mZKO//s MIME-Version: 1.0 X-Received: by 10.224.11.137 with SMTP id t9mr16574521qat.10.1415379889432; Fri, 07 Nov 2014 09:04:49 -0800 (PST) Received: by 10.229.250.4 with HTTP; Fri, 7 Nov 2014 09:04:49 -0800 (PST) In-Reply-To: <545CB930.3040305@redhat.com> 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> <545CB930.3040305@redhat.com> Date: Fri, 07 Nov 2014 17:04:00 -0000 Message-ID: Subject: Re: [PATCH v7] Events when inferior is modified From: Doug Evans To: Pedro Alves Cc: Nick Bull , gdb-patches Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2014-11/txt/msg00143.txt.bz2 On Fri, Nov 7, 2014 at 4:21 AM, Pedro Alves wrote: > 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.] One thing that occurs to me is that gdb can inform users when thread ids get recycled, not so with ptids. [An unlikely thing to need to worry about in general, but I'm all for being robust where we can.] Plus we can provide routines to map one to the other. [Hmmm, if we give out thread ids, do we need to attach a "generation number" or some such to them?] So at the moment I guess I'm undecided.