public inbox for rda@sourceware.org
 help / color / mirror / Atom feed
* Help required on rda [FRV]
@ 2005-04-06 10:58 Vinu Dev
  2005-04-06 20:06 ` Jim Blandy
  0 siblings, 1 reply; 6+ messages in thread
From: Vinu Dev @ 2005-04-06 10:58 UTC (permalink / raw)
  To: rda

Dear Jimb,
 I Appreciate your contribution to redhat on rda,i have problem using
rda compilied for FRV target,while debugging thread application using
rda and gdb compilied for FRV,there is a delay in thread creation when
compared to creation of thread running the prog on console.
 Can u pls guide me in solving this problem

Thread program used:thread.c

#include <stdio.h>
#include <pthread.h>
#include <sys/time.h>
#include <assert.h>

long initial_start_time;
long initial_end_time;

void *do_nothing(void *arg)
{
 struct timeval t;
 struct timezone tz;

 gettimeofday(&t, &tz);
printf("%d: Hello World!\n", arg);
   return NULL;
}

#define NUM_THREADS 1
int main(void)
{
   int i;
   pthread_t tid[NUM_THREADS];

 struct timeval t_start;
 struct timezone tz_start;

 struct timeval t_end;
 struct timezone tz_end;
 gettimeofday(&t_start, &tz_start);
  printf("Start  time %llu\n", t_start.tv_sec);
 initial_start_time = t_start.tv_sec;

   for (i = 0; i < NUM_THREADS; i++)
{
       printf("Creating thread %d\n", i);
   pthread_create(&tid[i], NULL, do_nothing, NULL);
}

   for(i =  0; i < NUM_THREADS; i++)
     pthread_join(tid[i], NULL);
 gettimeofday(&t_end, &tz_start);
  printf("End  time %llu\n", t_end.tv_sec);
 initial_end_time = t_end.tv_sec;

   return 0;
}

At target
#rda 1234 thread
Creating thread 0
Start  time 4054105993896787986
End  time 4054106032587143688
Total time take by the thread is time in sec 38654705694
Total time take by the thread is time in usec 1546188226560057
0: Hello World!
<wait_all_threads: 272 has exited>
<wait_all_threads: 272 has disappeared>
<wait_all_threads: 272 has disappeared>

At host
#frv-gdb thread
(gdb) target remote 192.168.1.174:1234
Remote debugging using 192.168.1.174:1234
0x00004de0 in ?? ()
(gdb) cont
Continuing.
[New Thread 16384]

Program exited normally.
(gdb)

Iam using RH9 at host side and at target its FRV kernel[2.4.24]

I would wait for ur reply.

Regards,
Vinay

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Help required on rda [FRV]
  2005-04-06 10:58 Help required on rda [FRV] Vinu Dev
@ 2005-04-06 20:06 ` Jim Blandy
  2005-04-07  5:01   ` Vinu Dev
  0 siblings, 1 reply; 6+ messages in thread
From: Jim Blandy @ 2005-04-06 20:06 UTC (permalink / raw)
  To: Vinu Dev; +Cc: rda


Vinu Dev <vinudev@gmail.com> writes:
>  I Appreciate your contribution to redhat on rda,i have problem using
> rda compilied for FRV target,while debugging thread application using
> rda and gdb compilied for FRV,there is a delay in thread creation when
> compared to creation of thread running the prog on console.
>  Can u pls guide me in solving this problem

Is your target system using LinuxThreads, or NPTL?

With LinuxThreads, debugging will slow down your program quite a bit;
there are a lot of signals the thread implementation sends itself
internally, and RDA catches each one.  I believe it re-reads the
thread table from the debuggee's memory each time it stops.

The timings your program prints are amazing, though; 38654705694
seconds is around a thousand years.  I assume you didn't have to wait
*that* long.  How long is the delay?

If you have the option of using NPTL, you might try using RDA from the
jimb-rda-nptl-branch branch.  I haven't had time to merge that into
the trunk, but hopefully I'll have some time to work on it eventually.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Help required on rda [FRV]
  2005-04-06 20:06 ` Jim Blandy
@ 2005-04-07  5:01   ` Vinu Dev
  2005-04-27  8:47     ` Jim Blandy
  0 siblings, 1 reply; 6+ messages in thread
From: Vinu Dev @ 2005-04-07  5:01 UTC (permalink / raw)
  To: Jim Blandy, rda

Dear JimB,
 Thanks for your reply,iam using LinuxThreads,its my requirement to
use linuxthreads.
   Even i was surprised by the delay factor,is there any other way to
measure the thread creation time more precise than using
gettimeofday() system call,if u could advice me on this,i would be
very much thankfull to you.
  The delay is around 4-5 secs for each thread creation via rda.
 Is there any article or technical documents or could u guide me to
know  the cause for this delay?

Regards
Vinay
  

On 06 Apr 2005 15:04:30 -0500, Jim Blandy <jimb@redhat.com> wrote:
> 
> Vinu Dev <vinudev@gmail.com> writes:
> >  I Appreciate your contribution to redhat on rda,i have problem using
> > rda compilied for FRV target,while debugging thread application using
> > rda and gdb compilied for FRV,there is a delay in thread creation when
> > compared to creation of thread running the prog on console.
> >  Can u pls guide me in solving this problem
> 
> Is your target system using LinuxThreads, or NPTL?
> 
> With LinuxThreads, debugging will slow down your program quite a bit;
> there are a lot of signals the thread implementation sends itself
> internally, and RDA catches each one.  I believe it re-reads the
> thread table from the debuggee's memory each time it stops.
> 
> The timings your program prints are amazing, though; 38654705694
> seconds is around a thousand years.  I assume you didn't have to wait
> *that* long.  How long is the delay?
> 
> If you have the option of using NPTL, you might try using RDA from the
> jimb-rda-nptl-branch branch.  I haven't had time to merge that into
> the trunk, but hopefully I'll have some time to work on it eventually.
> 
> 


-- 
Regards,
Vinay

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Help required on rda [FRV]
  2005-04-07  5:01   ` Vinu Dev
@ 2005-04-27  8:47     ` Jim Blandy
       [not found]       ` <18aafe4c05042803374d2b517b@mail.gmail.com>
  0 siblings, 1 reply; 6+ messages in thread
From: Jim Blandy @ 2005-04-27  8:47 UTC (permalink / raw)
  To: Vinu Dev; +Cc: rda


Vinu Dev <vinudev@gmail.com> writes:
> Dear JimB,
>  Thanks for your reply,iam using LinuxThreads,its my requirement to
> use linuxthreads.
>    Even i was surprised by the delay factor,is there any other way to
> measure the thread creation time more precise than using
> gettimeofday() system call,if u could advice me on this,i would be
> very much thankfull to you.
>   The delay is around 4-5 secs for each thread creation via rda.
>  Is there any article or technical documents or could u guide me to
> know  the cause for this delay?

4-5 seconds sounds about right.  If I remember correctly, it's due to
libthread_db's need to read huge amounts of memory from the program
being debugged each time it stops.

Take a look at rda/unix/linux-target.c:linux_process_rcmd.  That's the
function that gets called when you give GDB the "monitor" command.  So

        (gdb) monitor 1

(I think) should turn on debugging output in RDA, and

        (gdb) monitor 0

should turn it off.  If you'd like to be able to do other things to
RDA, you can add more stuff to linux_process_rcmd.

In any case, after 'monitor 1', RDA will print messages describing
all the ptrace calls it makes.  If I'm right, you'll see a *lot* of
ptrace traffic during those 4-5 seconds.

You might also try changing the initialization of thread_db_noisy to
1, to see more of what thread_db.c is doing.

Good luck!

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Help required on rda [FRV]
       [not found]       ` <18aafe4c05042803374d2b517b@mail.gmail.com>
@ 2005-05-16  4:20         ` Vinu Dev
  2005-05-16 21:14           ` Jim Blandy
  0 siblings, 1 reply; 6+ messages in thread
From: Vinu Dev @ 2005-05-16  4:20 UTC (permalink / raw)
  To: rda, jimb

Dear Jimb,
  Sorry for my late reply,as per ur advice i checked for  ptrace
traffic during those 4-5 seconds,It looks like large quantity of
PTRACE_PEEKTEXT-1 is  issued to target program from
rda,i tried recording those ptrace traffic,here is the sample of it 
************************************************************************
< -- failed, thread_agent = 0x00000000>
< -- failed, thread_agent = 0x00000000>
< -- failed, thread_agent = 0x00000000>
< -- failed, thread_agent = 0x00000000>
< -- failed, thread_agent = 0x00000000>
< -- failed, thread_agent = 0x00000000>
< -- failed, thread_agent = 0x00000000>
PTRACE_PEEKTEXT-1 0x02200690 in 266, 0x2a881000
PTRACE_POKETEXT 0x02200690 in 266, 0xffffffffc0700001
<ptrace (PTRACE_CONT, 266, 0, 0)>
<check_child_state: 266 got 'T' - 5 at 0x02200690>
<select_pending_event: pid 266 'T' 5>
wait returned 'T' (5) for 266.
PTRACE_GETFDPIC pid=266 offset=0 val=21ffcb0
PTRACE_GETFDPIC pid=266 offset=1 val=21ffca0
PTRACE_POKETEXT 0x02200690 in 266, 0x2a881000
PTRACE_PEEKTEXT-1 0x02204fe8 in 266, 0x00025068
PTRACE_PEEKTEXT-1 0x00025068 in 266, 0x021ffcb0
PTRACE_PEEKTEXT-1 0x0002506c in 266, 0x02204fe0
PTRACE_PEEKTEXT-1 0x00025070 in 266, 0x0001ee24
PTRACE_PEEKTEXT-1 0x00025074 in 266, 0x02204ebc
PTRACE_PEEKTEXT-1 0x00025078 in 266, 0x00025548
PTRACE_PEEKTEXT-1 0x0002507c in 266, 0x00000000
PTRACE_PEEKTEXT-1 0x00025548 in 266, 0x000257a0
PTRACE_PEEKTEXT-1 0x0002554c in 266, 0x0003cb60
PTRACE_PEEKTEXT-1 0x00025550 in 266, 0x00025530
PTRACE_PEEKTEXT-1 0x00025554 in 266, 0x0003c478
PTRACE_PEEKTEXT-1 0x00025558 in 266, 0x000257c0
PTRACE_PEEKTEXT-1 0x0002555c in 266, 0x00025068
PTRACE_PEEKTEXT-1 0x000257a0 in 266, 0x00000001
PTRACE_PEEKTEXT-1 0x000257a4 in 266, 0x00028000
PTRACE_PEEKTEXT-1 0x000257a8 in 266, 0x00000000
PTRACE_PEEKTEXT-1 0x000257ac in 266, 0x00056d20
PTRACE_PEEKTEXT-1 0x00025530 in 266, 0x2f6c6962
.
.
.
.
PTRACE_PEEKTEXT-1 0x000148dc in 266, 0xffffffff80880000
< -- failed, thread_agent = 0x00000000>
< -- failed, thread_agent = 0x00000000>
PTRACE_PEEKTEXT-1 0x0003783c in 266, 0x322e332e
PTRACE_PEEKTEXT-1 0x00037840 in 266, 0x332d6672
PTRACE_PEEKTEXT-1 0x00037844 in 266, 0x762d3034
PTRACE_PEEKTEXT-1 0x00037848 in 266, 0x30383230
PTRACE_PEEKTEXT-1 0x0003784c in 266, 0x2d330000
< -- failed, thread_agent = 0x0221e3f8>
PTRACE_PEEKTEXT-1 0x0003783c in 266, 0x322e332e
PTRACE_PEEKTEXT-1 0x00037840 in 266, 0x332d6672
PTRACE_PEEKTEXT-1 0x00037844 in 266, 0x762d3034
PTRACE_PEEKTEXT-1 0x00037848 in 266, 0x30383230
PTRACE_PEEKTEXT-1 0x0003784c in 266, 0x2d330000
< -- failed, thread_agent = 0x0221e3f8>
PTRACE_PEEKTEXT-1 0x0003783c in 266, 0x322e332e
************************************************************************************************
PTRACE_PEEKTEXT-1 is used by rda to get information from target
 program.  It read 4byte(unsigned long) data in each time.Now i
suspect this is reason why we are having the delay in debugging
thread.

Can u pls help me as 
1) Who issues these PTRACE_PEEKTEXT-1.
2) What cause this (why a large quantity of PTRACE_PEEKTEXT-1 issued to
   target program from rda)

Regards
Vinu





On 4/28/05, Vinu Dev <vinudev@gmail.com> wrote:
> ---------- Forwarded message ----------
> From: Jim Blandy <jimb@redhat.com>
> Date: 27 Apr 2005 03:45:03 -0500
> Subject: Re: Help required on rda [FRV]
> To: Vinu Dev <vinudev@gmail.com>
> Cc: rda@sources.redhat.com
> 
> Vinu Dev <vinudev@gmail.com> writes:
> > Dear JimB,
> >  Thanks for your reply,iam using LinuxThreads,its my requirement to
> > use linuxthreads.
> >    Even i was surprised by the delay factor,is there any other way to
> > measure the thread creation time more precise than using
> > gettimeofday() system call,if u could advice me on this,i would be
> > very much thankfull to you.
> >   The delay is around 4-5 secs for each thread creation via rda.
> >  Is there any article or technical documents or could u guide me to
> > know  the cause for this delay?
> 
> 4-5 seconds sounds about right.  If I remember correctly, it's due to
> libthread_db's need to read huge amounts of memory from the program
> being debugged each time it stops.
> 
> Take a look at rda/unix/linux-target.c:linux_process_rcmd.  That's the
> function that gets called when you give GDB the "monitor" command.  So
> 
>         (gdb) monitor 1
> 
> (I think) should turn on debugging output in RDA, and
> 
>         (gdb) monitor 0
> 
> should turn it off.  If you'd like to be able to do other things to
> RDA, you can add more stuff to linux_process_rcmd.
> 
> In any case, after 'monitor 1', RDA will print messages describing
> all the ptrace calls it makes.  If I'm right, you'll see a *lot* of
> ptrace traffic during those 4-5 seconds.
> 
> You might also try changing the initialization of thread_db_noisy to
> 1, to see more of what thread_db.c is doing.
> 
> Good luck!
> 
> --
> Regards,
> Vinay
> 


-- 
Regards,
Vinay

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Help required on rda [FRV]
  2005-05-16  4:20         ` Vinu Dev
@ 2005-05-16 21:14           ` Jim Blandy
  0 siblings, 0 replies; 6+ messages in thread
From: Jim Blandy @ 2005-05-16 21:14 UTC (permalink / raw)
  To: Vinu Dev; +Cc: rda


Vinu Dev <vinudev@gmail.com> writes:
> Can u pls help me as 
> 1) Who issues these PTRACE_PEEKTEXT-1.

These are probably the calls to ptrace-target.c:ps_pdread made by
libthread_db.  Try setting a breakpoint there.

> 2) What cause this (why a large quantity of PTRACE_PEEKTEXT-1 issued to
>    target program from rda)

As I said before:

> > 4-5 seconds sounds about right.  If I remember correctly, it's due to
> > libthread_db's need to read huge amounts of memory from the program
> > being debugged each time it stops.

Just to make sure you have the big picture: libthread_db.so is not the
thread library.  It is a library that *debuggers* link with to debug
multi-threaded programs.  The idea is that the debugger calls
functions in libthread_db to do things like get the list of all
threads, read a thread's registers, and so on.  libthread_db itself
calls back to functions in the debugger whose names start with 'ps_'
to do the actual reading and writing of memory, and access lightweight
processes' registers.

In theory, this allows the debugger to be ignorant of the details of
the thread library: libthread_db.so and libpthread.so are always
distributed as a pair, so as long as libthread_db.so is working, the
thread implementation could change without affecting the debugger.

In practice, thread implementations have gotten less complicated than
they used to be, and with NPTL libthread_db.so isn't worth the added
complexity.

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2005-05-16 21:14 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2005-04-06 10:58 Help required on rda [FRV] Vinu Dev
2005-04-06 20:06 ` Jim Blandy
2005-04-07  5:01   ` Vinu Dev
2005-04-27  8:47     ` Jim Blandy
     [not found]       ` <18aafe4c05042803374d2b517b@mail.gmail.com>
2005-05-16  4:20         ` Vinu Dev
2005-05-16 21:14           ` Jim Blandy

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).