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

[Alexander Smundak <asmundak@google.com>]

Ping.

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
>