Re: JIT interface slowness

[Paul Pluzhnikov <ppluzhnikov@google.com>]

On Mon, Jan 3, 2011 at 3:32 PM, Pedro Alves <pedro@codesourcery.com> wrote:

> gdb.base/ should be fine.
> gdb.gdb/ is for tests that load gdb itself as an inferior.

Ah, thanks.

>> diff -u -r1.8 jit.c
>
> Please use cvs diff -up.  -p makes wonders at making
> patches easier to read.

Sorry about that. It's been a long time since I sent patches, got rusty :-(

>> 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?

Right.

>> 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?

Did you mean "at most 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?

We probably wouldn't. I'll make a proper patch, measure, and send to
gdb-patches.

> (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.)

I'll fix that as well.

Thanks for comments!
-- 
Paul Pluzhnikov