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
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.
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
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!
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
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.