This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: JIT interface slowness
On Mon, Jan 3, 2011 at 9:32 AM, Paul Pluzhnikov <ppluzhnikov@google.com> wrote:
> 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).
I've reproduced this with current CVS Head.
I'd like to submit a test case for this, but where?
gdb.base/, gdb.gdb/, elsewhere?
I was also wrong about where the time is spent :-(
The quadratic/cubic loop does not in fact happen (it is protected against
with 'registering_code' in jit.c).
But I wasn't completely off base -- breakpoints to have something to do
with this. The profile (from 'perf') is:
# Events: 19K cycles
#
# Overhead Command Shared Object
Symbol
# ........ ......... ....................
........................................
#
67.30% gdb64-cvs gdb [.] lookup_minimal_symbol_text
29.59% gdb64-cvs gdb [.] lookup_minimal_symbol
0.81% gdb64-cvs gdb [.] find_pc_section
0.19% gdb64-cvs libc-2.11.1.so [.] __ctype_b_loc
And lookup_minimal_symbol_text is called from breakpoint_re_set:
10523 create_overlay_event_breakpoint ("_ovly_debug_event");
10524 create_longjmp_master_breakpoint ("longjmp");
10525 create_longjmp_master_breakpoint ("_longjmp");
10526 create_longjmp_master_breakpoint ("siglongjmp");
10527 create_longjmp_master_breakpoint ("_siglongjmp");
The following patch:
Index: jit.c
===================================================================
RCS file: /cvs/src/src/gdb/jit.c,v
retrieving revision 1.8
diff -u -r1.8 jit.c
--- 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.
Do we need a new OBJF_JIT flag, or is above patch good enough?
Thanks,
--
Paul Pluzhnikov