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

[Alexander Smundak <asmundak@google.com>]

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.