From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17734 invoked by alias); 16 May 2005 21:14:42 -0000 Mailing-List: contact rda-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Post: List-Help: , Sender: rda-owner@sources.redhat.com Received: (qmail 17711 invoked from network); 16 May 2005 21:14:38 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 16 May 2005 21:14:38 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id j4GLEcx0026271 for ; Mon, 16 May 2005 17:14:38 -0400 Received: from zenia.home.redhat.com (sebastian-int.corp.redhat.com [172.16.52.221]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id j4GLEaO25840; Mon, 16 May 2005 17:14:37 -0400 To: Vinu Dev Cc: rda@sources.redhat.com Subject: Re: Help required on rda [FRV] References: <18aafe4c05040603574ebfbd61@mail.gmail.com> <18aafe4c05040622017bc4ed22@mail.gmail.com> <18aafe4c05042803374d2b517b@mail.gmail.com> <18aafe4c050515211977e492a@mail.gmail.com> From: Jim Blandy Date: Mon, 16 May 2005 21:14:00 -0000 In-Reply-To: <18aafe4c050515211977e492a@mail.gmail.com> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2005-q2/txt/msg00005.txt.bz2 Vinu Dev 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.