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

[Pedro Alves <palves at redhat dot com>]

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