From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18486 invoked by alias); 11 Feb 2014 22:26:03 -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 18475 invoked by uid 89); 11 Feb 2014 22:26:02 -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-ve0-f181.google.com Received: from mail-ve0-f181.google.com (HELO mail-ve0-f181.google.com) (209.85.128.181) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Tue, 11 Feb 2014 22:26:01 +0000 Received: by mail-ve0-f181.google.com with SMTP id cz12so6568641veb.40 for ; Tue, 11 Feb 2014 14:25:59 -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=EmeDGNCLywCSPKho2B7N548qtPsNtF2pWD3nIyEmCcc=; b=O8dImZN0R2RazkEXpp2rnUBbgqT2NlgjZaoDh/dvPf4u1K23vkRofmB/025D15Mt/F XWXlFHW2QjCy1kxAR9DjTKFpIFLN1Xv+KApeuM1Z6AHYWtL1xFSrck3/GyWYRwfWlyPU zzUIY6h6bhuJTaIAAkOitB98kmcSdfcmB9OeK5kLeBnQH0dBH09OhSwu8NkgnZrksP5N tJufFAUu0ZWVlE+VPtKIOP5No7BFLnTUV1kV8r3qlNmgYS2Y53UgUiW0gSCj7ulORvJq GjX+Ts9qFUqQVv0gASeGPDcN8CvL3GYyuIXvbYWXwsXnqg7wFfKlhkfvgCfPnIQktPcD /IzA== X-Gm-Message-State: ALoCoQmPWOsg9mBKyHxApmIqTHASS9QMoPJIOpd/fSd6vB3jQl5Af35BnF0uiMfOiNll6wH05iqeNlzGMmwNPfoeh/seKmllZWTBcJG2VIxU/Y8zShdWNY9gECCZ3eJTXBlhWwZc/JAQEO3sBgnH7wo42QgIeLv5++dIwpD9yzbL78z1TRPZ+QiwOfkwk4X+qPUqbbaelDvPoaGO4TmiH/2BEKIgZhvzMA== MIME-Version: 1.0 X-Received: by 10.58.207.13 with SMTP id ls13mr30731123vec.13.1392157559518; Tue, 11 Feb 2014 14:25:59 -0800 (PST) Received: by 10.52.51.234 with HTTP; Tue, 11 Feb 2014 14:25:59 -0800 (PST) In-Reply-To: References: <20131226183618.D264CA18A0@sasha2.mtv.corp.google.com> <21204.13416.607204.485255@ruffy.mtv.corp.google.com> Date: Tue, 11 Feb 2014 22:26:00 -0000 Message-ID: Subject: Re: [RFC][PATCH] Allow JIT unwinder provide symbol information From: Doug Evans To: Alexander Smundak Cc: gdb-patches Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2014-02/txt/msg00368.txt.bz2 On Tue, Jan 14, 2014 at 4:39 PM, Alexander Smundak wrote: > I fixed the patch based on your comments, except for the one > about using LWP for thread identification. > Waiting for the opinions about the approach used in this RFC patch. > >> > +/* Returns LWP ID of the current thread or 0. */ >> > + >> > +typedef long (gdb_get_lwp) (void); >> >> The term "lwp" might be an insufficiently portable concept that we either >> need to pick a different name or use a different value here. >> It may be sufficient to stick with "lwp" but add further comments >> specifying how it's used so that one can translate it to whatever else >> is used on a non-lwp-using host. >> Alas I don't have a good answer. Hopefully someone else here does. > ... >> > +long >> > +jit_get_current_lwp (void) >> > +{ >> > + long lwp = ptid_get_lwp (inferior_ptid); >> > + >> > + // ptid_get_lwp returns 0 in the remote debugging case. Try getting >> > + // thread id then. >> > + // TODO(asmundak): perhaps use thread id always? >> > + return lwp ? lwp : ptid_get_tid (inferior_ptid); >> > +} >> >> In what situation does ptid_get_lwp return 0 for remote debugging? > If inferior is run by the gdbserver, I see that inferior.ptid.lwp > is 0, while inferior_ptid.tid is LWP. If inferior runs locally, it's > the opposite:inferior_ptid.lwp is LWP while inferior_ptid.tid is 0. Ah, righto. Blech. >> Also, getting back to whether "lwp" is sufficient portable, >> how does the external code use the value? > JVM maintains its own list of threads, using LWP as thread's unique > identifier.Java frame unwinder code checks that the frame belongs to > the thread it knows about. This feels like a case where a level of indirection is sufficient, the only hard part is picking a good name. IOW, if we replaced "lwp" with "jti" [Jit Thread Id] then I think that'd be sufficient (or even "jtid"). Java folks can even pretend the J is for Java and not Jit. :-) As for whether jti{,d} is a reasonable name ... dunno. If other's don't chime in within a week I'm going to make a Command Decision :-) and say let's go with that. And I'm happy to pick a different name. I just feel uncomfortable with using "lwp" since in the remote case while it is the lwp it comes from ptid.tid, and other systems may not use the term "lwp". I'm willing to be persuaded that using "lwp" here is just fine though.