nptl threads, gdb, Nsquared

nptl threads, gdb, Nsquared

[David Anderson]

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?

Thanks.
David Anderson davea at sgi dot com.

Re: nptl threads, gdb, Nsquared

[Andrew Cagney]

> 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