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