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

[Alexander Smundak]

I have looked again at the possibility of using Frame Filters.
They can be utilized as follows:
1. Use existing JIT reader API to unwind JIT frames.
2. Add methods to the Python Frame object to access frame's
stack pointer and frame pointer (or perhaps provide a method
to access any available register?)
3. Implement FrameDecorator that uses PC/FP/SP to retrieve
frame information (from JVM or whatever). Implement Frame
Filter that returns this FrameDecorator iterator.
4. Decide how to coordinate JIT reader and corresponding
Frame Filter loading.

Better?

On Tue, Apr 29, 2014 at 8:22 AM, Pedro Alves <palves@redhat.com> wrote:
> On 04/26/2014 12:39 AM, Alexander Smundak wrote:
>> On Thu, Apr 24, 2014 at 6:22 AM, Pedro Alves <palves@redhat.com> wrote:
>>> It seems to me that what you want to do here is what Python
>>> frame filters were invented for.  IOW, I think you should
>>> be able to write a frame filter that interacts with the Java
>>> JIT to expose the same info to the user your API extension
>>> is proposing.
>> The patch allows JIT readers to provide the symbol information to GDB.
>> I am not sure how this can be achieved with Python frame filters. IMHO
>> they have different purpose.
>
> But it doesn't actually provide symbol information.  Not in the sense
> that it hooks with GDB's symbol lookup mechanisms.
>
> E.g., the patch does this:
>
> @@ -1201,7 +1229,16 @@ print_frame (struct frame_info *frame, int print_level,
>        args_list_chain = make_cleanup_ui_out_list_begin_end (uiout, "args");
>        TRY_CATCH (e, RETURN_MASK_ERROR)
>   {
> -  print_frame_args (func, frame, numargs, gdb_stdout);
> +  const struct frame_symbol_info *frame_symbol;
> +  frame_symbol = get_frame_symbol_info (frame);
> +
> +  if (frame_symbol != NULL)
> +    {
> +      if (frame_symbol->arguments != NULL)
> + ui_out_text (uiout, frame_symbol->arguments);
> +    }
> +  else
> +    print_frame_args (func, frame, numargs, gdb_stdout);
>
> This is just wrong.  It's printing the frame arguments as
> a single, and simple string.  This simply doesn't work correctly
> with MI frontends.  Or what happens if the user selects
> one of those JIT frames and tries to print one of the arguments?
>
> I really think the way this patch is hooking a bespoke
> function/line/args mechanism into the frame machinery is
> quite hacky as is, sorry.  :-/
>
> --
> Pedro Alves
>