From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29404 invoked by alias); 2 Jun 2014 01:15:33 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 29385 invoked by uid 89); 2 Jun 2014 01:15:30 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-ob0-f173.google.com Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com) (209.85.214.173) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Mon, 02 Jun 2014 01:15:29 +0000 Received: by mail-ob0-f173.google.com with SMTP id wm4so3937545obc.32 for ; Sun, 01 Jun 2014 18:15:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=MWqoT1kxBSwaGnZ1RZN6WOdoaO8b2KFH/kwrgv8utI4=; b=NkQhJH4qPnYCMjEbqL9QOzrVhn+bPYtjyM3O0+L4U8BUt4+Lq+Awg3Wkre7UOouL4r 1ti0gcLkVE0hzqWbKHHdo2nz/fVQjlKa+Xh603jeWVTDXFN1ANbcGRpcqrBToI0iZBaY dNz4vmvaKxMrx9TmPuT1sv7dk1AFUteytUGJy+tjNC10Du8+qOlDiXYIbMSZBE8NYaJM h9jqtRpRGpxBQlybkMkyaGBZOHmASsjLfYmO8MDxKyhWzoHdL9346d0eQeFwVnmlYzDg gHfjqvYcV0NqacAvm/tlUkMnE8P64av6tWkEdED2fnclJbwR/X6HjnX/ojbBd/kekPAZ uPrg== X-Gm-Message-State: ALoCoQlJ1kU2BkNzJFi8G5lm3k0KZRg8jT8p3pZLjPTKlfh3SLigtID7FfTrEvx/AJccNXd/4Fil MIME-Version: 1.0 X-Received: by 10.182.33.106 with SMTP id q10mr34004110obi.19.1401671727176; Sun, 01 Jun 2014 18:15:27 -0700 (PDT) Received: by 10.182.144.133 with HTTP; Sun, 1 Jun 2014 18:15:26 -0700 (PDT) In-Reply-To: <535FC3AC.6030200@redhat.com> References: <20131226183618.D264CA18A0@sasha2.mtv.corp.google.com> <5359101B.1080603@redhat.com> <535FC3AC.6030200@redhat.com> Date: Mon, 02 Jun 2014 01:15:00 -0000 Message-ID: Subject: Re: [RFC][PATCH] Allow JIT unwinder provide symbol information From: Alexander Smundak To: Pedro Alves Cc: gdb-patches Content-Type: text/plain; charset=UTF-8 X-SW-Source: 2014-06/txt/msg00006.txt.bz2 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 wrote: > On 04/26/2014 12:39 AM, Alexander Smundak wrote: >> On Thu, Apr 24, 2014 at 6:22 AM, Pedro Alves 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 >