From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8491 invoked by alias); 29 Apr 2014 15:22:27 -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 8473 invoked by uid 89); 29 Apr 2014 15:22:26 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 29 Apr 2014 15:22:25 +0000 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s3TFMNAh012656 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 29 Apr 2014 11:22:23 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s3TFMLYA006731; Tue, 29 Apr 2014 11:22:22 -0400 Message-ID: <535FC3AC.6030200@redhat.com> Date: Tue, 29 Apr 2014 15:22:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: Alexander Smundak CC: gdb-patches Subject: Re: [RFC][PATCH] Allow JIT unwinder provide symbol information References: <20131226183618.D264CA18A0@sasha2.mtv.corp.google.com> <5359101B.1080603@redhat.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2014-04/txt/msg00617.txt.bz2 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