From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 56403 invoked by alias); 23 Mar 2016 19:32:34 -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 56392 invoked by uid 89); 23 Mar 2016 19:32:33 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=BAYES_00,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=Batch, UD:jpg, warm, ups X-HELO: mail-qk0-f175.google.com Received: from mail-qk0-f175.google.com (HELO mail-qk0-f175.google.com) (209.85.220.175) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Wed, 23 Mar 2016 19:32:23 +0000 Received: by mail-qk0-f175.google.com with SMTP id p130so11186191qke.1 for ; Wed, 23 Mar 2016 12:32:23 -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:from:date :message-id:subject:to:cc; bh=EwBu4MGlBa5M7QNtAStZTGh6VEfVGUsvXMYILD73XSE=; b=Pvg6J+S/NBF+/THWHTn7xl3DLt/3o8gC0HQxSXeYLYYNVKCsp3PKIrVDo8u0uavPU5 L6m9EfJDWpH7f/AkU9/G707HjAnh+UnpDWz3KXa2rwMGkNP9dTSTnCrZvsrUyKt0gvCi MjAH/19kpQEG0JqNr8HW6zviWhzhxPeBNyG0pM97GOKL5RriDy7fW4l0rEWH8ITg6P5A TFpa6uTwujUqEYNYpCVtCBPNtFHqCCXjnRXfDaQDmqVZViVLsITZNU8GOPP7YIpoSWXK AEUy0CtLiCd6igLFTT0oxuxhInhVwkbtccaAYLIbkXLfIzKlB8bvbVgDJpLSIuRegCiu r/vA== X-Gm-Message-State: AD7BkJJUJxID1iBsUdgv06uj5HHx1lElkAYz/Vu1tsMC2zt36XU0FGu6UIUEAlAzLkgWdt3deCWy0j8kCIMkSg== X-Received: by 10.55.72.148 with SMTP id v142mr5856570qka.102.1458761541339; Wed, 23 Mar 2016 12:32:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.189.130 with HTTP; Wed, 23 Mar 2016 12:32:01 -0700 (PDT) In-Reply-To: <56F2DF69.9030908@redhat.com> References: <56F168D7.9050405@redhat.com> <56F16F8F.9050404@redhat.com> <56F1759F.3070100@redhat.com> <56F17A23.90909@redhat.com> <56F2DF69.9030908@redhat.com> From: Yichao Yu Date: Wed, 23 Mar 2016 19:32:00 -0000 Message-ID: Subject: Re: JIT debugging (Attach and speed) To: Pedro Alves Cc: gdb@sourceware.org, Paul Pluzhnikov Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2016-03/txt/msg00042.txt.bz2 >> >> [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? With diff --git a/gdb/inline-frame.c b/gdb/inline-frame.c index f8ba249..49cae00 100644 --- a/gdb/inline-frame.c +++ b/gdb/inline-frame.c @@ -206,6 +206,7 @@ inline_frame_sniffer (const struct frame_unwind *self, struct frame_info *this_frame, void **this_cache) { + return 0; CORE_ADDR this_pc; const struct block *frame_block, *cur_block; int depth; The timing looks the same. =( > >> >>>>>> 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.? What do you mean by "loader"? since you mentioned call JIT_REGISTER I assume you mean JIT compiler? At least for the julia JIT, we already try to batch compile as much as we can (this is also necessary to save memory for example, since most functions are much smaller than a page) However, it is impossible to know all the functions a program is going to call so there'll be continues jitting going on. For normal program this shouldn't be that bad since it should execute a small number of functions most of the time and the jit don't need to work anymore after some initial warm up. However, the test suite is a very case since it is written to call all the functions with many different types which will force the compiler to emit a lot of functions and run them. > > 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 >