From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24906 invoked by alias); 27 Sep 2006 21:02:41 -0000 Received: (qmail 24894 invoked by uid 22791); 27 Sep 2006 21:02:39 -0000 X-Spam-Check-By: sourceware.org Received: from nf-out-0910.google.com (HELO nf-out-0910.google.com) (64.233.182.191) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 27 Sep 2006 21:02:37 +0000 Received: by nf-out-0910.google.com with SMTP id k26so640012nfc for ; Wed, 27 Sep 2006 14:02:34 -0700 (PDT) Received: by 10.49.90.4 with SMTP id s4mr2858241nfl; Wed, 27 Sep 2006 14:02:34 -0700 (PDT) Received: from ?87.1.99.122? ( [87.1.99.122]) by mx.gmail.com with ESMTP id y24sm4143520nfb.2006.09.27.14.02.32; Wed, 27 Sep 2006 14:02:33 -0700 (PDT) Message-ID: <451AE760.4080507@gmail.com> Date: Wed, 27 Sep 2006 21:02:00 -0000 From: Carmelo Amoroso Reply-To: carmelo73@gmail.com User-Agent: Thunderbird 1.5.0.5 (Macintosh/20060719) MIME-Version: 1.0 To: Michael Snyder CC: gdb@sourceware.org Subject: Re: howto debug libthread_db References: <45193401.7000502@gmail.com> <1159294840.24808.76.camel@localhost.localdomain> <451A18E9.9070500@gmail.com> <1159380919.9768.39.camel@localhost.localdomain> In-Reply-To: <1159380919.9768.39.camel@localhost.localdomain> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-09/txt/msg00172.txt.bz2 Michael Snyder wrote: > On Wed, 2006-09-27 at 08:23 +0200, Carmelo Amoroso wrote: >> Michael Snyder wrote: >>> On Tue, 2006-09-26 at 16:06 +0200, Carmelo Amoroso wrote: >>>> Hi All, >>>> I'm trying to debug a simple multithread application on a remote target, >>>> and I like to debug the libthread_db itself... is it possible to do it? >>>> is it possible to set some breakpoints and stepping through? >>>> Is there anyone already played with it? >>>> >>>> I tried to use symbol-file to gdb client, and I successfully added a >>>> breakpoint, but I cannot reach it after I connected to the target and >>>> issued 'continue'. >>>> >>>> Any help will be appreciated >>> Interesting. I haven't done it (or not much anyway). >>> >>> The first thing you must bear in mind is that libthread_db is not >>> part of the target application -- it is part of gdb (or in the >>> remote debugging context, part of gdbserver). So to debug it, >>> you must debug gdb, or in your case gdbserver. >>> >> Yes. it's what I want to do > >>> It might be easier if you try this out first using a native gdb, >>> debugging itself. >>> >>> When you debug gdb with gdb, it is easier if you change the prompt. >>> I usually do this in the 'parent' gdb, so I can tell it apart from >>> the 'child' gdb: >>> >>> (gdb) set prompt (GDB) >>> (GDB) >>> >>> Now, in the parent GDB, you should be able to set your >>> breakpoints in libthread_db, then start the child gdb, >>> load the multi-threaded program, and begin debugging it. >>> >> Does the native gdb use the thread_db as the gdbserver does? > > Yes. > >> I was thinking to run gdb --args my-gdbserver >> on the target, and connect to the my-gdbserver from the host >> just to trigger the thread_db initialization process. >> Comments? > > Oh, so you can actually run gdb on the target? Yes, I'm using it after I read your reply. So I'm running a working gdb (glibc/sh4 based) to debug a half-working gdbserver (uClibc-nptl/sh4 based). I was able to set breakpoint on gdbserver itself (thread_db_find_new_threads function for example) and to step into my thread_db library. But up to now I could not reach the td_ta_map_lp2thr function due to some failures in packets transmission between gdb remote client and target gdbserver, so the tbread_db initializaition is failing before entering in that function. I'm still working on it. I'd like to describe the problem I have in case some one may have an idea: The stack is as follows: td_ta_map_lwp2thr iterate_list_thread td_ta_thr_iter thread_db_find_new_threads thread_db_init The td_ta_map_lwp2thr funtcion reach its end successfully (performing any symbol lookup; I also printed out the thread pointer and its value is just the same as printed by the pthread_self function from the libpthread), but when returns to the caller it produces a SIGSEV due to a misaligned access (as reported by dmesg command). Any printf after the function's invocation is never executed! The thread_db code is he same as the glibc, so I cannot understand where it's failing. The gdbserver version is 6.4 (built using a sh4-linux-gcc configured for uClibc) and it is the same code used to build the glibc based version. > Yes, that would make things simpler, and what you > suggest above is pretty much what I would recommend. > > >>> When you get ready to try this with gdbserver, you will >>> have to start one gdbserver and attach to it with another >>> gdbserver. Then you'll again have two gdbs running on the >>> host side, which you can again think of as parent and child, >>> only now the parent is debugging the child's gdbserver, not >>> the child gdb itself. >>> >> Well, just before reading your reply, I tried with this: >> >> target: >> gdbserver localhost:999 my-gdbserver localhost:998 >> >> host: >> xxx-gdb my-gdbserver (connecting to port 999) >> >> xxx-gdb application (connecting to port 998) >> >> With the first gdb session I was able to set a breakpoint into >> thread_db, but not able to stepping through the code. >> >> Is this approach as well as the gdb native session. > > Hmmm, that's pretty much what I would have tried. > What happened when you tried to step? How did it fail? > Difficult to describe; I'm trying to follow the native approach for now, but I'd like trying this again later; I'll report any failure or success with more details. Thanks a lot again Carmelo