From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16808 invoked by alias); 25 Feb 2014 03:00:26 -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 16789 invoked by uid 89); 25 Feb 2014 03:00:25 -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-oa0-f47.google.com Received: from mail-oa0-f47.google.com (HELO mail-oa0-f47.google.com) (209.85.219.47) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Tue, 25 Feb 2014 03:00:23 +0000 Received: by mail-oa0-f47.google.com with SMTP id h16so3004946oag.6 for ; Mon, 24 Feb 2014 19:00:21 -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:content-type; bh=SWhQTNCllHW8d21YpodlwJW7Fpr3jgMRIRBNywUnXcs=; b=BWueS31ufSIyW9xTZlb0uGH40l94Eit2oHJCPoqF1MkIzhDSoVyLUTrSNHpsCSFfal YrHJ3zeEcRBI8g/+R2/D8/nBUJqvXbjP8YzDT4wOOmtVLLRLwGF/pIfh3UZV+cXYXe3c M3hQTWZFJ2VidqXT6uUo6B2igOOrvt9EYUN5Wp/c3cSEDl1PukmgicQzZHZBvJ/d0ckv 1SNloihkeHF09U5qjxOY2Q+N9bKsR+zOx9TQyU+A1hWWqRMCzNp67UbLhgw96dSXcoE8 sYZ/k8ZJ/+5lQQrnJpKIFXKfvR3eGaUkpqKi+lmFCAiSgYoc5PUvm9gA/+/ipIkAyakA u1aA== X-Gm-Message-State: ALoCoQmCf4CpOVR6hLmUjnHWQSJJVBoyjRIKhQc6rSsugVP9eKi12DcT8OlISDcjO2jFrGSwlbbx7rImOw5e1Xc+qv/m3aO09jWeaag0MQKlddx/qTauAS5NURreiqycRI7PKHmdUY4lUCDPtc9T681tLeTsAqIx624ZC3KCWLPwkF+of+MenaYKFAilBxzgvVdulgzxWl9kAcfvWliJgBSr/SPleRyXyw== MIME-Version: 1.0 X-Received: by 10.60.45.38 with SMTP id j6mr24663783oem.2.1393297221676; Mon, 24 Feb 2014 19:00:21 -0800 (PST) Received: by 10.182.84.131 with HTTP; Mon, 24 Feb 2014 19:00:21 -0800 (PST) In-Reply-To: References: <20131226183618.D264CA18A0@sasha2.mtv.corp.google.com> <21204.13416.607204.485255@ruffy.mtv.corp.google.com> Date: Tue, 25 Feb 2014 03:00:00 -0000 Message-ID: Subject: Re: [RFC][PATCH] Allow JIT unwinder provide symbol information From: Alexander Smundak To: gdb-patches Content-Type: text/plain; charset=UTF-8 X-SW-Source: 2014-02/txt/msg00745.txt.bz2 I will address the remaining issues in two days and will post the new patch. On Mon, Feb 24, 2014 at 5:19 PM, Doug Evans wrote: > On Tue, Feb 11, 2014 at 11:50 PM, Doug Evans wrote: >> On Tue, Feb 11, 2014 at 2:25 PM, Doug Evans wrote: >>> 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); >> >> Another issue that occurs to me is what if the loaded jit shared >> library on some platform (not necessarily linux) wants to use >> ptid.tid, even if both ptid.lwp and ptid.tid are available? >> >> Does it make sense to provide routines that access each? >> >> Pedro, the issue is what handle on a thread to export to the >> jit-reader-load shared library. >> Java for linux wants the lwp, and currently the patch will return >> ptid.tid instead of ptid.lwp if lwp == 0 to shield the shared lib >> from gdb vs gdbserver thread ptid usage differences, on the assumption >> that if lwp == 0 then tid is actually lwp. >> >> On a separate note, >> IIRC we still have to decide how to handle version 1 jit-reader-load >> shared libs. > > Hi all. > In an attempt to keep this patch moving along here are my current thoughts. > > The lwp vs tid issue has been resolved by cleaning up gdb's own > internal usage of the values so now a remote connection should provide > the user the same values as a local connection. > > And given that there are two values, I'm less inclined to invent > something and think we should just go with gdb_get_lwp for now. Later > we can add gdb_get_tid if a user comes along that needs it. [I'm > happy to add it now of course if someone really wants to.] > > Thus I think(!) the only remaining issues are: > - jit-reader-load version 1 support. > - update documentation > - testcase for new functionality > - testcase to verify version 1 API still works > We can't break jit readers that have been compiled with the version 1 API. > [Well, IWBN if we had a published mechanism to migrate users of > deprecated APIs to newer versions, but that's a separate discussion.] > > Can you update the patch to handle the remaining TODOs? > I can do that if you want, just let me know. > Enough time has passed for comments that I think we can proceed with > the final details. > [I didn't audit your last patch/changelog for code style and other > nits. I'm saving that for once all the main TODOs are done.]