From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19553 invoked by alias); 25 Feb 2014 01:19:52 -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 19541 invoked by uid 89); 25 Feb 2014 01:19:51 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.9 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-qc0-f177.google.com Received: from mail-qc0-f177.google.com (HELO mail-qc0-f177.google.com) (209.85.216.177) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Tue, 25 Feb 2014 01:19:50 +0000 Received: by mail-qc0-f177.google.com with SMTP id m20so1554050qcx.36 for ; Mon, 24 Feb 2014 17:19:48 -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=HmXEpxOFfZPxbkBKuUtRtiVO2Bc+9dROgu/ThkMcpTE=; b=gSMf1VtuND5tYhDFd8vEUGonK6x4IYNEvWmC1bV975BU3zD5kRjflI/VOwdxknqjxD ECF98Q6zv06IVF2j4fSt9uh398jEFC8xR+qT9w2onCz7x747C2SpbtvAHbQp2iUGQZ3E LuV+zUmf4ghEqgexk32QRSFGMxVPBEBRhMQjY4iDQx/q0h/bxlalTgdR9JRvtgh84uWv uUwE7O1MXzczhZtfRg2t8/es8pjxBVtTy9WVU9ksJJ/++9Mln0OcWqaMdWdw5TsDTJI+ Ha4yv9ED5bbdC7ZJ1ADbVEh2vAawENILaRpErNYGwIaKt/g2+QGy1IkgYDi32DQFmYhw ahnQ== X-Gm-Message-State: ALoCoQkz1PTJYjX++43Zi8ChubFOteLhPxvAOpgdt2OJlWX4D16du8mqoqPXaFRxhw+niqyOAamRgxLNlAVBHxDirU9l5vXw5wMYXm2cDuw46xq2y584UTjITO7tSfff+i8HZnwp4M1o86UGf65NWaUkl3cDuV8dx2a2CIjp/aZ32gg8TfgQUOEELowpI6A6vDvuIYa/0YIBnT7nrSx5oEacL6nam3wFWQ== MIME-Version: 1.0 X-Received: by 10.140.87.204 with SMTP id r70mr32846684qgd.23.1393291188284; Mon, 24 Feb 2014 17:19:48 -0800 (PST) Received: by 10.229.109.72 with HTTP; Mon, 24 Feb 2014 17:19:48 -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 01:19:00 -0000 Message-ID: Subject: Re: [RFC][PATCH] Allow JIT unwinder provide symbol information From: Doug Evans To: Alexander Smundak Cc: gdb-patches , Pedro Alves Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2014-02/txt/msg00744.txt.bz2 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.]