From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26087 invoked by alias); 30 Sep 2006 16:46:15 -0000 Received: (qmail 26079 invoked by uid 22791); 30 Sep 2006 16:46:13 -0000 X-Spam-Check-By: sourceware.org Received: from nf-out-0910.google.com (HELO nf-out-0910.google.com) (64.233.182.186) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 30 Sep 2006 16:46:09 +0000 Received: by nf-out-0910.google.com with SMTP id k26so1353408nfc for ; Sat, 30 Sep 2006 09:46:05 -0700 (PDT) Received: by 10.49.8.15 with SMTP id l15mr3270752nfi; Sat, 30 Sep 2006 09:46:05 -0700 (PDT) Received: from ?87.6.111.197? ( [87.6.111.197]) by mx.gmail.com with ESMTP id m15sm10514338nfc.2006.09.30.09.46.03; Sat, 30 Sep 2006 09:46:05 -0700 (PDT) Message-ID: <451E9FC4.5040304@gmail.com> Date: Sat, 30 Sep 2006 16:46: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> <451AE760.4080507@gmail.com> <2ccd6e3c0609290208m3d79e87ak33b737c7a3a20fe6@mail.gmail.com> <1159553569.9768.264.camel@localhost.localdomain> In-Reply-To: <1159553569.9768.264.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/msg00194.txt.bz2 Michael Snyder wrote: > On Fri, 2006-09-29 at 11:08 +0200, Carmelo Amoroso wrote: >> Well, >> after a few days of debugging my gdbserver (with uClibc-nptl on sh4), >> I found the bug into uClibc, >> that was causing a stack frame corruption due to a buffer overrun. >> This was the reason for which the td_ta_map_lwp2thr was never >> returning to the caller >> (the stack location where the PR had been saved was corupted). >> >> It was a very interesting debugging session. I successfully used a >> native gdb (glibc base)on target >> to debug a gdbserver (uClinc-nptl based) I connect to with a gdb >> client from a linux host. >> >> At the end I did not need to use a double remote gdb session. >> >> Thanks to Michael for his very usefull tips. > > > So, does that mean that there was no actual problem with gdb, > with respect to stepping in libthread_db? Yes, it was my thread_db that was failing killing the gdbserver This works now? Yes, it works perfectly, even with multithreadrd applications. Carmelo > > Thanks, > Michael > > >> On 9/27/06, Carmelo Amoroso wrote: >>> 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 >>> >