From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10106 invoked by alias); 3 Jan 2011 23:32:46 -0000 Received: (qmail 10098 invoked by uid 22791); 3 Jan 2011 23:32:46 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,TW_BJ,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 03 Jan 2011 23:32:32 +0000 Received: (qmail 6225 invoked from network); 3 Jan 2011 23:32:30 -0000 Received: from unknown (HELO orlando.localnet) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 3 Jan 2011 23:32:30 -0000 From: Pedro Alves To: Paul Pluzhnikov Subject: Re: JIT interface slowness Date: Mon, 03 Jan 2011 23:32:00 -0000 User-Agent: KMail/1.13.5 (Linux/2.6.33-29-realtime; KDE/4.4.5; x86_64; ; ) Cc: Vyacheslav Egorov , gdb@sourceware.org References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201101032332.28548.pedro@codesourcery.com> 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/msg00009.txt.bz2 Hi Paul, thanks for the tests, stats and for looking into this. On Monday 03 January 2011 22:00:48, Paul Pluzhnikov wrote: > I'd like to submit a test case for this, but where? > gdb.base/, gdb.gdb/, elsewhere? gdb.base/ should be fine. gdb.gdb/ is for tests that load gdb itself as an inferior. > diff -u -r1.8 jit.c Please use cvs diff -up. -p makes wonders at making patches easier to read. (I just put "diff -up" in ~/.cvsup). > --- jit.c 1 Jan 2011 15:33:09 -0000 1.8 > +++ jit.c 3 Jan 2011 21:34:17 -0000 > @@ -263,7 +263,7 @@ > my_cleanups = make_cleanup (clear_int, ®istering_code); > > /* This call takes ownership of sai. */ > - objfile = symbol_file_add_from_bfd (nbfd, 0, sai, OBJF_SHARED); > + objfile = symbol_file_add_from_bfd (nbfd, SYMFILE_DEFER_BP_RESET, > sai, OBJF_SHARED); > > /* Clear the registering_code flag. */ > do_cleanups (my_cleanups); > > > makes 100x difference (0.64s vs. 61.5s) for 1000 simulated JIT ELFs. > > I think it's pretty safe to assume that we don't need to search JITted > objfiles for above functions, as JITs do not participate in normal symbol > resolution at all. But doesn't that mean that pending breakpoints on JITed functions won't resolve anymore? > Do we need a new OBJF_JIT flag, or is above patch good enough? What if we record a per-objfile flag or cache storing whether a given objfile contains "longjmp" related symbols, so that we only lookup those symbols at least once per DSO? Quite similar in spirit to your objc_objfile_data change. Do we still get a significant slowdown from breakpoint_re_set with that change? (I've also noticed before that lookup_minimal_symbol_text iterates over all objfiles even if given an objfile to work with (worse case, but then again, new objfiles are appended at the end of the objfile list). Probably contributes to the noise, but these things add up.) -- Pedro Alves