This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFC][PATCH] Allow JIT unwinder provide symbol information
- From: Alexander Smundak <asmundak at google dot com>
- To: Pedro Alves <palves at redhat dot com>
- Cc: gdb-patches <gdb-patches at sourceware dot org>
- Date: Sun, 1 Jun 2014 18:15:26 -0700
- Subject: Re: [RFC][PATCH] Allow JIT unwinder provide symbol information
- Authentication-results: sourceware.org; auth=none
- References: <20131226183618 dot D264CA18A0 at sasha2 dot mtv dot corp dot google dot com> <5359101B dot 1080603 at redhat dot com> <CAHQ51u40jadvuYqmYBqs4yFnFy96HZ46GmKpj3=_V3G9NSF12w at mail dot gmail dot com> <535FC3AC dot 6030200 at redhat dot com>
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
>