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

[Alexander Smundak <asmundak at google dot com>]

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 <dje@google.com> wrote:
> 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.]