Re: JIT interface slowness

[Pedro Alves <pedro@codesourcery.com>]

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, &registering_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