From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21970 invoked by alias); 15 Jan 2014 00:39:49 -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 21951 invoked by uid 89); 15 Jan 2014 00:39:47 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 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-ob0-f170.google.com Received: from mail-ob0-f170.google.com (HELO mail-ob0-f170.google.com) (209.85.214.170) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Wed, 15 Jan 2014 00:39:46 +0000 Received: by mail-ob0-f170.google.com with SMTP id uy5so439446obc.1 for ; Tue, 14 Jan 2014 16:39:44 -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=9v9/ijBVDR/MTvTUHOgpV32Gd6vRauSkgUgaadBDF9k=; b=V9+us/M/y5SJnjPMkEcWXpt6umkjNJ4QK5QQVW2Y8LmqXeibF9myQdOidwiC+LYfRi dKLGIRw1KIqAT/HNYjLjfB+LYdilm63Li9NAVK0Vd8CLLvucOvkpszCeEdp518r/VXZS 3iSxMoNfoTg/dP8Lkhu3Fb/luqX/imEmxxspHyXjzjMtotmok9cfh4ViZ+ADxVeYRGLg ooCwEU5kw+Uox0OeYRY09bhnBR7z+hwS+B33T72AdmbXa4ybSTorg7nKAFWX+aBLJFrq XCcnf4O6mViLno27eC6ptClOHAaWreo/BHEa1Ptcfh3jobU2iA++VWezgvYCt+gcNg3K JbBw== X-Gm-Message-State: ALoCoQkuT4k2ZEP9lwvsEe/RFe3OkDfZNBHaXAaN5EE+I2zHOyMc/e7sKqSYdlOEa7PejUJkkW/05YpQRr7kWu/CRAO6jdORMGvGGWNvxyPm8GxMaqdldEzak5v0rc+DgWgG0gTyINXXvroegdYwhtd+jHSz1brc/7JIO9YcXFQLPxV3yTMqj5OXGCWcUB2L4kXGRC47WEEjD+LyfHyMFT/suvQ3SJnd0w== MIME-Version: 1.0 X-Received: by 10.60.92.102 with SMTP id cl6mr3611522oeb.59.1389746384610; Tue, 14 Jan 2014 16:39:44 -0800 (PST) Received: by 10.182.179.37 with HTTP; Tue, 14 Jan 2014 16:39:44 -0800 (PST) In-Reply-To: <21204.13416.607204.485255@ruffy.mtv.corp.google.com> References: <20131226183618.D264CA18A0@sasha2.mtv.corp.google.com> <21204.13416.607204.485255@ruffy.mtv.corp.google.com> Date: Wed, 15 Jan 2014 00:39:00 -0000 Message-ID: Subject: Re: [RFC][PATCH] Allow JIT unwinder provide symbol information From: Alexander Smundak To: Doug Evans Cc: gdb-patches@sourceware.org Content-Type: text/plain; charset=UTF-8 X-SW-Source: 2014-01/txt/msg00485.txt.bz2 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. > 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.