Re: [RFC][PATCH] Allow JIT unwinder provide symbol information

[Doug Evans <dje@google.com>]

On Tue, Feb 11, 2014 at 11:50 PM, Doug Evans <dje@google.com> wrote:
> On Tue, Feb 11, 2014 at 2:25 PM, Doug Evans <dje@google.com> wrote:
>> On Tue, Jan 14, 2014 at 4:39 PM, Alexander Smundak <asmundak@google.com> 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.]