why is gdb 5.2 so slow

why is gdb 5.2 so slow

[wim delvaux]

I have been working with gdb 4.xx for years.

because of the dynamic library breakpoint handing I moved to 5.2 only to find 
it VERY slow.  I wrote this mail because I just had to kill gdb because it 
consumed 100 % cpu for MINUTES without doing anything usefull.

I run debian (testing version with the latests versions) I have currently 
installed 5.2.cvs 2002081.

Kernel version 2.4.18

I must admin that I do not have the fastest workhorse imaginable (a PIII 800) 
but that used to be no problem.

I also sometimes use ddd 3.1 with gdb and again in the 4-version I had no 
problem, executing was crips, debugging (almost) fun.

Now it skips breakpoints, takes ages to skip to the next statement, sometimes 
does not even want to stop (because it refers to some missing thread or 
something).  Only killing is the solution.

PLEASE help me out here !!!!

W

Re: why is gdb 5.2 so slow

[Daniel Jacobowitz]

On Fri, Nov 01, 2002 at 02:32:19AM +0100, wim delvaux wrote:
> I have been working with gdb 4.xx for years.
> 
> because of the dynamic library breakpoint handing I moved to 5.2 only to find 
> it VERY slow.  I wrote this mail because I just had to kill gdb because it 
> consumed 100 % cpu for MINUTES without doing anything usefull.
> 
> I run debian (testing version with the latests versions) I have currently 
> installed 5.2.cvs 2002081.
> 
> Kernel version 2.4.18
> 
> I must admin that I do not have the fastest workhorse imaginable (a PIII 800) 
> but that used to be no problem.
> 
> I also sometimes use ddd 3.1 with gdb and again in the 4-version I had no 
> problem, executing was crips, debugging (almost) fun.
> 
> Now it skips breakpoints, takes ages to skip to the next statement, sometimes 
> does not even want to stop (because it refers to some missing thread or 
> something).  Only killing is the solution.
> 
> PLEASE help me out here !!!!

We can't help you unless you give us more information, of course.

What are you doing?  If you're complaining about slowness, you're
probably working with multithreaded applications.  Yeah, it's slower,
but better.  Every once in a while I work on making it faster but I
haven't had much success yet.

It should not spin for minutes on its own.  What were you telling it to
do?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: why is gdb 5.2 so slow

[wim delvaux]

>
> We can't help you unless you give us more information, of course.

	Yes indeed, threads, lots of threads !

	The applications are not large but have a lot of dynamically loaded
	libraries, which, btw, has another annoying effect that when you 
	start gdb on a core file you have to press ENTER (q does not seem to work)
	a few times because of the 'loading symbol messages'.  Can you get rid of
	that prompt ?

	To give an example if you step over a function with 'n' it sometimes takes 5 
seconds to skip over that function (even if that function is nog complex at 
all)

	What should i be looking at to give you more info.

	Thanx for the reply

Re: why is gdb 5.2 so slow

[Andrew Cagney]

>>
>> We can't help you unless you give us more information, of course.
> 
> 
> 	Yes indeed, threads, lots of threads !
> 
> 	The applications are not large but have a lot of dynamically loaded
> 	libraries, which, btw, has another annoying effect that when you 
> 	start gdb on a core file you have to press ENTER (q does not seem to work)
> 	a few times because of the 'loading symbol messages'.  Can you get rid of
> 	that prompt ?

Can you file a bug?  http://sources.redhat.com/gdb/bugs/  Yes, that 
would quickly become frustrating.

A workaround is to add `set height 0' to your .gdbinit file.

> 	To give an example if you step over a function with 'n' it sometimes takes 5 
> seconds to skip over that function (even if that function is nog complex at 
> all)

I think you won the lottery in finding GDB's current known worst case :-)

Daniel, humor me here ...

GDB, to implement a thread-hop (step a single thread over a breakpoint) 
with something like (with a Linux Kernel):

- gdb is notifed of a thread stopped on a breakpoint (wait), call this 
the `current thread'
- gdb obtains that threads registers
more ptrace
- gdb stops (signal/wait) all the other threads
forall threads signal/wait
- gdb pulls all the breakpoints
forall breakpoins ptrace
- gdb single-steps the `current thread'
ptrace/wait
- gdb plants all the breakpoints
forall breakpoints ptrace/ptrace
- gdb resumes all threads
forall threads ptrace

A single-step is similar.  I suspect that GDB debugging a multi-threaded 
shared library uses lots of thread-hops and lots of single steps :-(. 
GDB is either doing this very inefficiently (a lot more than the above) 
or there are some straightforward performance tweaks (step out of 
range?).  It could also turn out, though, that the above is as good as 
it gets :-(

I'd suspect a combination of both.  This is because I recently noticed 
that on another OS (Hi JasonT) I noticed that it was a separate ptrace() 
to fetch each PPC register, even though ptrace() returns all 32 PPC 
registers in a single hit :-(.  Anyway, my things-to-do-today is 
ktrace/oprofile GDB and see just how badly GDB is hitting the kernel. 
I've been told verbally it's pretty bad.

On a bright note, I've also been told that a future Linux Kernel is 
going to support a stop all threads primative so that at least some of 
the above stupidity can be eliminated.

Andrew

Re: why is gdb 5.2 so slow

[wim delvaux]

> Can you file a bug?  http://sources.redhat.com/gdb/bugs/  Yes, that
> would quickly become frustrating.

	Done ... example attached

>
> A workaround is to add `set height 0' to your .gdbinit file.

	Will try that, thanx.  Indeed the number of prompts is related to
	the window size.

>
> I think you won the lottery in finding GDB's current known worst case :-)

	If I look at your explanation i think indeed I have the EXTREME situation
	here. I can easily have about 10 threads and about 60 dynamically loaded
	libraries and as said my PC is NOT the most powerfull ;-(

	Thanx again for the reply

Re: why is gdb 5.2 so slow

[Daniel Jacobowitz]

On Fri, Nov 01, 2002 at 04:15:17PM +0100, wim delvaux wrote:
> 
> > Can you file a bug?  http://sources.redhat.com/gdb/bugs/  Yes, that
> > would quickly become frustrating.
> 
> 	Done ... example attached
> 
> >
> > A workaround is to add `set height 0' to your .gdbinit file.
> 
> 	Will try that, thanx.  Indeed the number of prompts is related to
> 	the window size.
> 
> >
> > I think you won the lottery in finding GDB's current known worst case :-)
> 
> 	If I look at your explanation i think indeed I have the EXTREME situation
> 	here. I can easily have about 10 threads and about 60 dynamically loaded
> 	libraries and as said my PC is NOT the most powerfull ;-(
> 
> 	Thanx again for the reply

Knew I forgot to suggest something.

If you don't need watchpoint support, please try running your program
under gdbserver instead of directly in GDB.  It should be buckets
faster.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: why is gdb 5.2 so slow

[wim delvaux]

>
> If you don't need watchpoint support, please try running your program
> under gdbserver instead of directly in GDB.  It should be buckets
> faster.

	Thanx, I will try that and report effect

	

Re: why is gdb 5.2 so slow

[Daniel Jacobowitz]

On Fri, Nov 01, 2002 at 09:58:03AM -0500, Andrew Cagney wrote:
> 
> GDB, to implement a thread-hop (step a single thread over a breakpoint) 
> with something like (with a Linux Kernel):
> 
> - gdb is notifed of a thread stopped on a breakpoint (wait), call this 
> the `current thread'
> - gdb obtains that threads registers
> more ptrace
> - gdb stops (signal/wait) all the other threads
> forall threads signal/wait
> - gdb pulls all the breakpoints
> forall breakpoins ptrace
> - gdb single-steps the `current thread'
> ptrace/wait
> - gdb plants all the breakpoints
> forall breakpoints ptrace/ptrace
> - gdb resumes all threads
> forall threads ptrace
> 
> A single-step is similar.  I suspect that GDB debugging a multi-threaded 
> shared library uses lots of thread-hops and lots of single steps :-(. 
> GDB is either doing this very inefficiently (a lot more than the above) 
> or there are some straightforward performance tweaks (step out of 
> range?).  It could also turn out, though, that the above is as good as 
> it gets :-(
> 
> I'd suspect a combination of both.  This is because I recently noticed 
> that on another OS (Hi JasonT) I noticed that it was a separate ptrace() 
> to fetch each PPC register, even though ptrace() returns all 32 PPC 
> registers in a single hit :-(.  Anyway, my things-to-do-today is 
> ktrace/oprofile GDB and see just how badly GDB is hitting the kernel. 
> I've been told verbally it's pretty bad.

Both.  Things we do wrong:
- GDB can't handle being told that just one thread is stopped.  If we
could, then we wouldn't have to stop all threads for shared library
events; there's a mutex in the system library so we don't even have to
worry about someone hitting the breakpoint.  We could also use this to
save time on conditional breakpoints; if we aren't stopping, why stop
all other threads?

- Removing all breakpoints, that's just wrong, there's a test in
signals.exp (xfailed :P) which shows why.  We should _only_ be removing
any breakpoints at the address we're hopping over.

- No memory cache by default.  thread_db spends a LOT of time reading
from the inferior.

- No ptrace READDATA request for most Linux targets to read a large
chunk.  I keep submitting patches for some other ptrace cleanups that
will let me add this one to the kernel, and they keep hitting a blank
wall.  I may start maintaining 2.4 patches publicly and see if people
use them!

- Too many calls to thread_db in the LinuxThreads case.  It's a nice
generic layer but implemented such that the genericity (? :P) comes
with a severe cost in performance.  We need most of the layer; I've
seen the NGPT support patch for GDB, and it's very simple, precisely
because of this layer.  But we could do staggeringly better if we just
had a guarantee that there was a one-to-one, unchanging LWP<->thread
correspondence (no userspace scheduling etc.).  Both LinuxThreads and
the new NPTL library have this property.  Then we don't need to use
thread_db to access the inferior at all, only to collect new thread
information.

Want a sample of how much difference this last one makes?  In
combination with a bit of my first bullet above, that means we don't
have to stop all threads at a new thread event?  Use gdbserver instead
of GDB.  Its completely from-scratch threads support does not work with
NGPT or any other N:M threading library, but for N:N it is drastically
faster.  The spot that's still slowest is shared library events,
because we can't report that just that thread stopped and ask if we
should stop others (or better, be told by GDB that the breakpoint at
that address is a don't-stop-all-threads breakpoint).

That's just off the top of my head.  I think there are a few more.

> On a bright note, I've also been told that a future Linux Kernel is 
> going to support a stop all threads primative so that at least some of 
> the above stupidity can be eliminated.

Some "future"...  I've seen the code in question, I think; it's nice
but no one has had the time to push it properly, so it won't be until
2.7 at the earliest, I'd say.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: why is gdb 5.2 so slow

[Andrew Cagney]

> Both.  Things we do wrong:
> - GDB can't handle being told that just one thread is stopped.  If we
> could, then we wouldn't have to stop all threads for shared library
> events; there's a mutex in the system library so we don't even have to
> worry about someone hitting the breakpoint.  We could also use this to
> save time on conditional breakpoints; if we aren't stopping, why stop
> all other threads?

[my guess] If the condition fails, we need to thread-hop.  If the 
condition succeeds we need to stop all threads anyway.

Knowing that shlibs are wrapped in a mutex is definitly something to 
exploit.

> - Removing all breakpoints, that's just wrong, there's a test in
> signals.exp (xfailed :P) which shows why.  We should _only_ be removing
> any breakpoints at the address we're hopping over.
> 
> - No memory cache by default.  thread_db spends a LOT of time reading
> from the inferior.

Based on a verbal description I was given, I believe that the current 
dcache model is slightly wrong.  It should behave more like the regcache 
vis:
- ask for one register, get back the register file
hence:
- ask for one byte, get back one page, OR
- ask for one byte, mmap the entire target process address space
That way the target decides.

HP, long ago, was proposing zero copy target memory accesses.

> - No ptrace READDATA request for most Linux targets to read a large
> chunk.  I keep submitting patches for some other ptrace cleanups that
> will let me add this one to the kernel, and they keep hitting a blank
> wall.  I may start maintaining 2.4 patches publicly and see if people
> use them!

Uli (glibc), KevinB, MichaelS, and I happened to be in the same room and 
talked about this.  /procfs was suggested as an alternative path.  For 
ptrace() Uli indicated something about running out of register arguments 
to use across a system call.

> - Too many calls to thread_db in the LinuxThreads case.  It's a nice
> generic layer but implemented such that the genericity (? :P) comes
> with a severe cost in performance.  We need most of the layer; I've
> seen the NGPT support patch for GDB, and it's very simple, precisely
> because of this layer.  But we could do staggeringly better if we just
> had a guarantee that there was a one-to-one, unchanging LWP<->thread
> correspondence (no userspace scheduling etc.).  Both LinuxThreads and
> the new NPTL library have this property.  Then we don't need to use
> thread_db to access the inferior at all, only to collect new thread
> information.

Apparently that guarentee is comming.  Solaris, for instance, is moving 
back to 1:1.  My instinct is that reduceing the system calls will make a 
far greater improvement than trimming back glibc.

> Want a sample of how much difference this last one makes?  In
> combination with a bit of my first bullet above, that means we don't
> have to stop all threads at a new thread event?  Use gdbserver instead
> of GDB.  Its completely from-scratch threads support does not work with
> NGPT or any other N:M threading library, but for N:N it is drastically
> faster.  The spot that's still slowest is shared library events,
> because we can't report that just that thread stopped and ask if we
> should stop others (or better, be told by GDB that the breakpoint at
> that address is a don't-stop-all-threads breakpoint).
> 
> That's just off the top of my head.  I think there are a few more.
> 
> 
>> On a bright note, I've also been told that a future Linux Kernel is 
>> going to support a stop all threads primative so that at least some of 
>> the above stupidity can be eliminated.
> 
> 
> Some "future"...  I've seen the code in question, I think; it's nice
> but no one has had the time to push it properly, so it won't be until
> 2.7 at the earliest, I'd say.

Andrew

Re: why is gdb 5.2 so slow

[Daniel Jacobowitz]

On Fri, Nov 01, 2002 at 11:55:26AM -0500, Andrew Cagney wrote:
> 
> >Both.  Things we do wrong:
> >- GDB can't handle being told that just one thread is stopped.  If we
> >could, then we wouldn't have to stop all threads for shared library
> >events; there's a mutex in the system library so we don't even have to
> >worry about someone hitting the breakpoint.  We could also use this to
> >save time on conditional breakpoints; if we aren't stopping, why stop
> >all other threads?
> 
> [my guess] If the condition fails, we need to thread-hop.  If the 
> condition succeeds we need to stop all threads anyway.

Oh, blast it.  So we can't use this for general conditional
breakpoints.  If the condition is true we stop all threads before
giving a prompt; if the condition is false we stop all threads in order
to step over the breakpoint.

We could do thread-specific breakpoints hit by the wrong thread this
way... and thread-specific conditional breakpoints hit by the right
thread but with the condition false could _probably_ be done this way
but implementing it would be complicated.

Now, thread-specific breakpoints hit by the wrong thread could be used
to speed up "next"/software-single-step...

> Knowing that shlibs are wrapped in a mutex is definitly something to 
> exploit.
> 
> >- Removing all breakpoints, that's just wrong, there's a test in
> >signals.exp (xfailed :P) which shows why.  We should _only_ be removing
> >any breakpoints at the address we're hopping over.
> >
> >- No memory cache by default.  thread_db spends a LOT of time reading
> >from the inferior.
> 
> Based on a verbal description I was given, I believe that the current 
> dcache model is slightly wrong.  It should behave more like the regcache 
> vis:
> - ask for one register, get back the register file
> hence:
> - ask for one byte, get back one page, OR
> - ask for one byte, mmap the entire target process address space
> That way the target decides.
> 
> HP, long ago, was proposing zero copy target memory accesses.
> 
> >- No ptrace READDATA request for most Linux targets to read a large
> >chunk.  I keep submitting patches for some other ptrace cleanups that
> >will let me add this one to the kernel, and they keep hitting a blank
> >wall.  I may start maintaining 2.4 patches publicly and see if people
> >use them!
> 
> Uli (glibc), KevinB, MichaelS, and I happened to be in the same room and 
> talked about this.  /procfs was suggested as an alternative path.  For 
> ptrace() Uli indicated something about running out of register arguments 
> to use across a system call.

I don't know what he's referring to... wait... request, pid, len,
target address, buffer.  x86 can only do four.  Crappy but it could be
worked around.

In any case, this reminded me of something I keep forgetting.  Modern
kernels a ptrace-attached process can open the child's /proc/<pid>/mem
and read from it.  Writing to it is disabled, and mmap is not
implemented (oh the violence to the mm layer if that was allowed!). 
But reading from it is probably faster than PTRACE_PEEKTEXT.  I'll
investigate.

> >- Too many calls to thread_db in the LinuxThreads case.  It's a nice
> >generic layer but implemented such that the genericity (? :P) comes
> >with a severe cost in performance.  We need most of the layer; I've
> >seen the NGPT support patch for GDB, and it's very simple, precisely
> >because of this layer.  But we could do staggeringly better if we just
> >had a guarantee that there was a one-to-one, unchanging LWP<->thread
> >correspondence (no userspace scheduling etc.).  Both LinuxThreads and
> >the new NPTL library have this property.  Then we don't need to use
> >thread_db to access the inferior at all, only to collect new thread
> >information.
> 
> Apparently that guarentee is comming.  Solaris, for instance, is moving 
> back to 1:1.  My instinct is that reduceing the system calls will make a 
> far greater improvement than trimming back glibc.

Well, I'd hate to lose NGPT support; like it or not a lot of people
(especially in the carrier-grade space) are starting to use it.  At the
same time we don't need to be using the heavyweight interface when it
isn't needed.


-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: why is gdb 5.2 so slow

[Andrew Cagney]

>> [my guess] If the condition fails, we need to thread-hop.  If the 
>> condition succeeds we need to stop all threads anyway.
> 
> 
> Oh, blast it.  So we can't use this for general conditional
> breakpoints.  If the condition is true we stop all threads before
> giving a prompt; if the condition is false we stop all threads in order
> to step over the breakpoint.

Well, the conditional expression could be pushed down into the target 
(aka kernel) as byte codes.  Part of that introspect stuff.  That way 
the kernel could co-ordinate it.

> We could do thread-specific breakpoints hit by the wrong thread this
> way... and thread-specific conditional breakpoints hit by the right
> thread but with the condition false could _probably_ be done this way
> but implementing it would be complicated.

But GDB needs to do thread specific breakpoints anyway :-)

> Now, thread-specific breakpoints hit by the wrong thread could be used
> to speed up "next"/software-single-step...
> 

>> Uli (glibc), KevinB, MichaelS, and I happened to be in the same room and 
>> talked about this.  /procfs was suggested as an alternative path.  For 
>> ptrace() Uli indicated something about running out of register arguments 
>> to use across a system call.
> 
> 
> I don't know what he's referring to... wait... request, pid, len,
> target address, buffer.  x86 can only do four.  Crappy but it could be
> worked around.
> 
> In any case, this reminded me of something I keep forgetting.  Modern
> kernels a ptrace-attached process can open the child's /proc/<pid>/mem
> and read from it.  Writing to it is disabled, and mmap is not
> implemented (oh the violence to the mm layer if that was allowed!). 
> But reading from it is probably faster than PTRACE_PEEKTEXT.  I'll
> investigate.

Ah.  How does solaris work then?

>> Apparently that guarentee is comming.  Solaris, for instance, is moving 
>> back to 1:1.  My instinct is that reduceing the system calls will make a 
>> far greater improvement than trimming back glibc.
> 
> 
> Well, I'd hate to lose NGPT support; like it or not a lot of people
> (especially in the carrier-grade

Bingo!

>   space) are starting to use it.  At the
> same time we don't need to be using the heavyweight interface when it
> isn't needed.

(By NGPT I'm guessing that you mean N:M threads) I don't think GDB will 
loose that - it will always need to support things like N:1.  It's just 
that for 1:1 threads, the implementation can be shaved down to nothing.

Andrew

Re: why is gdb 5.2 so slow

[Kevin Buettner]

On Nov 1,  1:32pm, Andrew Cagney wrote:

> > In any case, this reminded me of something I keep forgetting.  Modern
> > kernels a ptrace-attached process can open the child's /proc/<pid>/mem
> > and read from it.  Writing to it is disabled, and mmap is not
> > implemented (oh the violence to the mm layer if that was allowed!). 
> > But reading from it is probably faster than PTRACE_PEEKTEXT.  I'll
> > investigate.
> 
> Ah.  How does solaris work then?

On Solaris, /proc provides a complete debug interface.  On Linux, it doesn't.

Kevin

Re: why is gdb 5.2 so slow

[Nick Kelsey]

> Both.  Things we do wrong:
> - GDB can't handle being told that just one thread is stopped.  If we
> could, then we wouldn't have to stop all threads for shared library
> events; there's a mutex in the system library so we don't even have to
> worry about someone hitting the breakpoint.  We could also use this to
> save time on conditional breakpoints; if we aren't stopping, why stop
> all other threads?
> --
> Daniel Jacobowitz
> MontaVista Software                         Debian GNU/Linux Developer

We have exactly this problem at the moment - our system supports setting
breakpoints that only stop specified threads, however GDB cannot use this
support at the moment. If you have an interest for this support then I would
be interested in your thoughts.

Nick

Nick Kelsey
Senior Software Engineer
Ubicom

RE: why is gdb 5.2 so slow

[Howell, David P]

Hi Daniel,
See my comments mixed in below with [DPH].

Thanks,
Dave Howell

-----Original Message-----
From: Daniel Jacobowitz [mailto:drow@mvista.com] 
Sent: Friday, November 01, 2002 10:17 AM
To: Andrew Cagney
Cc: wim delvaux; gdb@sources.redhat.com
Subject: Re: why is gdb 5.2 so slow

On Fri, Nov 01, 2002 at 09:58:03AM -0500, Andrew Cagney wrote:
> 
> GDB, to implement a thread-hop (step a single thread over a
breakpoint) 
> with something like (with a Linux Kernel):
> 
	<< Stuff Deleted >>

> Both.  Things we do wrong:
> - GDB can't handle being told that just one thread is stopped.  If we
> could, then we wouldn't have to stop all threads for shared library
> events; there's a mutex in the system library so we don't even have to
> worry about someone hitting the breakpoint.  We could also use this to
> save time on conditional breakpoints; if we aren't stopping, why stop
> all other threads?
[DPH] Depends on what is being done. If going to a prompt to allow the 
	user to examine the state or running breakpoint commands, we may

	not want other threads doing things to change it. It is an 
	expensive thing to do but I expect that we'd find a lot of other

	issues if this changes. 

> - Removing all breakpoints, that's just wrong, there's a test in
> signals.exp (xfailed :P) which shows why.  We should _only_ be
removing
> any breakpoints at the address we're hopping over.
[DPH] I thought we need this to show a clean program space, i.e. without

	gdb's modifications, i.e. breakpoints. My guess is that the code
is
	general that does this and we'd have to put more logic in to
detect 
	when we are poking in the address space after the breakpoint.
>
> - No memory cache by default.  thread_db spends a LOT of time reading
> from the inferior.
[DPH] From what I've looked at this is the big baddie. Lots of pulling
of 
	thread state using ptrace in 4 byte nibbles (IA32
w/linuxthreads). 
	A 'strace -f -o /tmp/trc gdb myprog' is humbling on this front,
there
	are thousands/millions of these calls for stuff like 'info
threads' 
	and other thread operations.

	Some of this can be eliminated with thread_db caching, lots of
the 
	operations are repeats that could be resolved in a cache if the
state
	of the inferior doesn't change and all threads are stopped.
Also, the
	implementation of libthread_db can be fixed to eliminate some of
it
	by eliminating any unnecessary inferior pokes. 

> - No ptrace READDATA request for most Linux targets to read a large
> chunk.  I keep submitting patches for some other ptrace cleanups that
> will let me add this one to the kernel, and they keep hitting a blank
> wall.  I may start maintaining 2.4 patches publicly and see if people
> use them!
[DPH] Yeah, this would help a lot. Is there a reason that 4 byte ptraces
are
	necessary? Some standard or common convention/practice? I
thought of
      using /proc/<pid>/mem with memcpy, but haven't found the time to
flesh
	it out yet. Anyway, if ptrace directly supports it that would
resolve 
	this.

> - Too many calls to thread_db in the LinuxThreads case.  It's a nice
> generic layer but implemented such that the genericity (? :P) comes
> with a severe cost in performance.  We need most of the layer; I've
> seen the NGPT support patch for GDB, and it's very simple, precisely
> because of this layer.  
[DPH] Thanks, that was mine for NGPT. I had on my list caching and
single
	ptrace operations for large inferior block accesses as the next
best
	improvements to make. Minimizing the info pulled as well would
help,
	we currently pull the complete thread structure where we could
define
	a subset that we care about to pull to cut the load. Decoupling
from
	the real structure has support headaches about it though, when
things 
	change the abbreviated structure would need changes.

> But we could do staggeringly better if we just
> had a guarantee that there was a one-to-one, unchanging LWP<->thread
> correspondence (no userspace scheduling etc.).  Both LinuxThreads and
> the new NPTL library have this property.  Then we don't need to use
> thread_db to access the inferior at all, only to collect new thread
> information.
[DPH] Architectures that do M:N will be around for a while, not sure
that 
	this is the right thing to do. Can we make the LWP layer lighter

	for the cases where it's not used? 

> Want a sample of how much difference this last one makes?  In
> combination with a bit of my first bullet above, that means we don't
> have to stop all threads at a new thread event?  Use gdbserver instead
> of GDB.  Its completely from-scratch threads support does not work
with
> NGPT or any other N:M threading library, but for N:N it is drastically
> faster.  The spot that's still slowest is shared library events,
> because we can't report that just that thread stopped and ask if we
> should stop others (or better, be told by GDB that the breakpoint at
> that address is a don't-stop-all-threads breakpoint).
[DPH] I still would vote for the generality to cover the options
available
	in the Linux community, including M:N. But what is there can be
	improved a bunch.
>
> -- 
> Daniel Jacobowitz
> MontaVista Software                         Debian GNU/Linux Developer

David Howell
Intel Corporation
Telco Server Development
Server Products Division
Voice: (803) 461-6112  Fax: (803) 461-6292

Intel Corporation
Columbia Design Center, CBA-2
250 Berryhill Road, Suite 100
Columbia, SC 29210

david.p.howell@intel.com

Re: why is gdb 5.2 so slow

[Andrew Cagney]

>> - Removing all breakpoints, that's just wrong, there's a test in
>> signals.exp (xfailed :P) which shows why.  We should _only_ be
> 
> removing
> 
>> any breakpoints at the address we're hopping over.
> 
> [DPH] I thought we need this to show a clean program space, i.e. without
> 
> 	gdb's modifications, i.e. breakpoints. My guess is that the code
> is
> 	general that does this and we'd have to put more logic in to
> detect 
> 	when we are poking in the address space after the breakpoint.

No.

Breakpoints are pulled to ensure that the target is clean when [not if 
:-)] gdb barfs / is killed / ....  Attach GDB to a process, set a few 
breakpoints, continue the process, and then shoot GDB.  The process 
quickly dies with a SIGTRAP from one of those, still in memory, breakpoints.

GDB does have methods that present a clean program space.   Using those 
functions, and not pulling breakpoints, should largely involve legwork. 
  However, things like single-step and thread-hop would be more 
complicated involving a bit of think-o to get right.

What would really help is for the kernel to provide an option where it 
rips out out any stray breakpoints after a detach.  That way GDB could 
safely enable this by default.

Andrew

Re: why is gdb 5.2 so slow

[Jim Blandy]

Andrew Cagney <ac131313@redhat.com> writes:
> What would really help is for the kernel to provide an option where it
> rips out out any stray breakpoints after a detach.  That way GDB could
> safely enable this by default.

I've heard it suggested that, for this behavior, the kernel shouldn't
know about breakpoints specifically, since those need all sorts of
other support (GDB has to be ptracing and waiting, etc.).  Instead,
the kernel would provide some way for a debugger to make some memory
writes (e.g., breakpoints) --- but not others (e.g., variable
modifications) --- via a special interface that would revert the
writes when the GDB process exited or died.

The ways I can think of to implement this involve page table magic,
which makes me wonder if one couldn't actually use them for per-thread
breakpoints and thread hops, too.  That is, if the debugger could make
one thread see the program text differently from the others, then it
could pull the breakpoint for that thread alone, while leaving it in
for the others.  No thread hop necessary.

I'm of out my depth here, though --- I've never looked at Linux's mm
layer, for example, and don't understand its limitations.  Just an
idea.