* 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
[parent not found: <18aafe4c05042803374d2b517b@mail.gmail.com>]
* 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).