From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1325 invoked by alias); 3 Jan 2011 17:32:52 -0000 Received: (qmail 1317 invoked by uid 22791); 3 Jan 2011 17:32:52 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,RCVD_IN_DNSWL_LOW,SPF_HELO_PASS,TW_BJ,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.44.51) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 03 Jan 2011 17:32:46 +0000 Received: from wpaz9.hot.corp.google.com (wpaz9.hot.corp.google.com [172.24.198.73]) by smtp-out.google.com with ESMTP id p03HWidJ009782 for ; Mon, 3 Jan 2011 09:32:44 -0800 Received: from qyk27 (qyk27.prod.google.com [10.241.83.155]) by wpaz9.hot.corp.google.com with ESMTP id p03HWejO002548 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Mon, 3 Jan 2011 09:32:43 -0800 Received: by qyk27 with SMTP id 27so15817500qyk.15 for ; Mon, 03 Jan 2011 09:32:43 -0800 (PST) Received: by 10.224.11.144 with SMTP id t16mr20129916qat.99.1294075962957; Mon, 03 Jan 2011 09:32:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.67.222 with HTTP; Mon, 3 Jan 2011 09:32:12 -0800 (PST) In-Reply-To: References: <201012312222.54063.pedro@codesourcery.com> <201012312336.08222.pedro@codesourcery.com> From: Paul Pluzhnikov Date: Mon, 03 Jan 2011 17:32:00 -0000 Message-ID: Subject: Re: JIT interface slowness To: Vyacheslav Egorov Cc: Pedro Alves , gdb@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true X-IsSubscribed: yes 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 X-SW-Source: 2011-01/txt/msg00005.txt.bz2 On Mon, Jan 3, 2011 at 2:43 AM, Vyacheslav Egorov wrote: > I thought that setting a breakpoint requires O(1) not O(n). It's a bit > disappointing. I think I've mis-diagnosed the problem slightly -- there is no breakpoint inserted into every JITted ELF. But there is still a quadratic loop in jit.c: /* Look up the objfile with this code entry address. */ static struct objfile * jit_find_objf_with_entry_addr (CORE_ADDR entry_addr) { struct objfile *objf; CORE_ADDR *objf_entry_addr; ALL_OBJFILES (objf) { objf_entry_addr = (CORE_ADDR *) objfile_data (objf, jit_objfile_data); if (objf_entry_addr != NULL && *objf_entry_addr == entry_addr) return objf; } return NULL; } ... static void jit_inferior_init (struct gdbarch *gdbarch) ... /* If we've attached to a running program, we need to check the descriptor to register any functions that were already generated. */ for (cur_entry_addr = descriptor.first_entry; cur_entry_addr != 0; cur_entry_addr = cur_entry.next_entry) { jit_read_code_entry (gdbarch, cur_entry_addr, &cur_entry); /* This hook may be called many times during setup, so make sure we don't add the same symbol file twice. */ if (jit_find_objf_with_entry_addr (cur_entry_addr) != NULL) continue; jit_register_code (gdbarch, cur_entry_addr, &cur_entry); } This is quadratic if you insert all 1000 JITted ELFs and call the __jit_debug_register_code() once. If you call __jit_debug_register_code() after adding every new ELF, you get N*N*N instead :-( My gut feeling though is that the really slow operation here is jit_read_code_entry (which reads target memory) and everything else is noise in comparison (but I haven't measured it). Assuming this is so, you get O(N) if you call __jit_debug_register_code once, and O(N*N) if you call it after every new ELF. I think we could do much better if we keep a "shadow" copy of the list of JITted ELFs in GDB, instead of re-reading it from inferior all the time. Let me try to come up with a patch ... > I will have to emit debug information (namely .debug_frame) > for all code object otherwise gdb is not able to unwind stack properly > on x64. This is slightly incorrect: you must emit .eh_frame{,_hdr} for any x86_64 code if you want stack unwinder to work, but you don't need to emit any debug info (IOW, .debug_frame is not required). Cheers, -- Paul Pluzhnikov