This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: gdb and dlopen
>
> I'm absolutely sure. Or at least, I was... when I tested this, it was
> an obvious win. Now it is an obvious LOSS to turn on the cache. I'm
> not sure why, so I'll have to investigate it later. In 5.0.90-cvs it
> was a win and in current trunk it is a significant performance loss.
>
> This is in the context of a linuxthreads application. We do a
> ridiculous, staggering amount of memory transfer in order to debug a
> linuxthreads application, and parts of it are duplicated.
Hmm, In the context of threads, trying to use the insn/data cache is
cheating :-)
The problem with threads is that GDB is constantly discarding its per
thread information. Only to immediatly turn around and ask that that
same information be re-created. GDB, when switching between threads,
should retain that information in the the ``struct thread_info''. Even
register information could be cached on a per-thread basis.
See
http://sources.redhat.com/gdb/papers/multi-arch/real-multi-arch/index.html#SEC37
enjoy,
Andrew