From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 112281 invoked by alias); 23 Mar 2016 18:24:54 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 112257 invoked by uid 89); 23 Mar 2016 18:24:53 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=shortcut, UD:jpg, 1500, ups 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 (AES256-GCM-SHA384 encrypted) ESMTPS; Wed, 23 Mar 2016 18:24:43 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id 876FA6445D; Wed, 23 Mar 2016 18:24:42 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u2NIOfZq029029; Wed, 23 Mar 2016 14:24:41 -0400 Subject: Re: JIT debugging (Attach and speed) To: Yichao Yu References: <56F168D7.9050405@redhat.com> <56F16F8F.9050404@redhat.com> <56F1759F.3070100@redhat.com> <56F17A23.90909@redhat.com> Cc: gdb@sourceware.org, Paul Pluzhnikov From: Pedro Alves Message-ID: <56F2DF69.9030908@redhat.com> Date: Wed, 23 Mar 2016 18:24:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2016-03/txt/msg00041.txt.bz2 On 03/23/2016 04:51 AM, Yichao Yu wrote: >>>>> Yeah, there's no full fix available, only some ideas thrown out. >>>>> The last discussed one wouldn't cause a regression -- the >>>>> "longjmp"-caching idea. We may still need to defer breakpoint re-set >>>>> to at most once per jit load event, something like Paul's original >>>>> patch, but with a breakpoint_re_set call somewhere. > > I've just run the profile myself and got some quite different result > from the 2011 thread[1]. > With no breakpoint in gdb and simply jitting O(2000) functions: [2] > With one (un-triggered) breakpoint in gdb and jitting O(1500) functions: [3] > > It seems that there's other slowness when there are breakpoint created > but in terms of scaling, the fastest growing one is the sorting in > `update_section_map` > > [1] https://sourceware.org/ml/gdb/2011-01/msg00009.html > [2] http://i.imgur.com/6Ca6Yal.jpg > [3] http://i.imgur.com/aHKGACX.jpg Ouch. Not sure what to do here. Maybe we could cache something above find_pc_section -> update_section_map, to avoid the section look ups. From [2], we see that this is in the inline frame sniffer. Maybe we can add a shortcut here, based on assuming that if we're stopped at the jit event breakpoint address, then we're not stopped at an inlining site. That is, a trick similar to the pc_at_non_inline_function check in infrun.c. So, as a quick hack, if you make inline_frame_sniffer bail out early with 0, does it improve things? > >>>>> It'd even be better to somehow restrict breakpoint re-setting >>>>> to the jit modules that were added/removed/changed, but >>>>> that's harder. > > I've re-read the 2011 thread and I think I have a slightly better > understanding now. IIUC we need to check if the newly registered file > contains any pending breakpoints. Is the problem that this is done by > checking it over all the registered object files? Is it possible to > avoid O(n^2) scaling without only re-setting on the jit object file > currently being modified? Batch loading the object files comes to mind. From reading the code, it seems like gdb only reads on object file per JIT_REGISTER event. The descriptor->relevant_entry one. Is that correct? Is there a reason the loader couldn't batch compile all functions, only call the JIT_REGISTER once, and then have GDB follow descriptor->relevant_entry->next_entry, etc.? If we could batch load, then we could also defer breakpoint re-set until all is loaded, as well as inhibit section map updates, as done in svr4_handle_solib_event for normal DSO loading. Thanks, Pedro Alves