This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: JIT interface slowness

On Mon, Jan 3, 2011 at 3:32 PM, Pedro Alves <> 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?


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

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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]