Re: nptl threads, gdb, Nsquared

[Andrew Cagney <cagney at gnu dot org>]

> I'd be pleased to be wrong here. but it seems that with nptl
> pthreads apps under gdb on GNU/Linux that (oversimplifing 
> significantly) register saving is N-squared:
>
> Say there are N registers (around 300 for Intel Itanium)
>
> regcache_save(), for each register  call do_cooked_read()
>   For each register,i.e, N times, do_cooked_read calls
>     thread_db_fetch_registers calls on libthread_db.so requesting
>     all registers (libthread_db.so calls back  to ps_lgetregs() in gdb
>     which requests _all_ registers and calls to thread_db_fetch_registers).
>     For each register  fetch_register () in inf_ptrace.c 
>       is called (Loading is now N**2) .
>
> So each register fetch of 300 regs results in fetching 300*300 registers.
>
> This is painfully slow.
>
> Have I got this all wrong?
> I presume this is well known though.
> Comments? References to gdb threads/bug-reports?

The code fetching all registers should have marked each register as 
valid as it was extracted from the inferior - see regcache_raw_supply. 
Consequently later reads are [should] be pulled from the regcache 
avoiding the expensive ptrace call.

(btw, infptrace.c, not inf-ptrace.c) (which reminds me ...)

> Thanks.
> David Anderson davea at sgi dot com.

Andrew