From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30260 invoked by alias); 19 May 2013 08:04:14 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 30248 invoked by uid 89); 19 May 2013 08:04:14 -0000 X-Spam-SWARE-Status: No, score=-5.1 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL,RP_MATCHES_RCVD autolearn=ham version=3.3.1 Received: from smtp.checkpoint.com (HELO smtp.checkpoint.com) (194.29.34.68) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Sun, 19 May 2013 08:04:13 +0000 Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r4J848wi010816; Sun, 19 May 2013 11:04:08 +0300 X-CheckPoint: {51988554-9-1B221DC2-1FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.54]) by DAG-EX10.ad.checkpoint.com ([169.254.3.48]) with mapi id 14.02.0342.003; Sun, 19 May 2013 11:04:09 +0300 From: Avi Gozlan To: Doug Evans CC: "gdb@sourceware.org" Subject: RE: GDB and libthread_db.so.1 issue Date: Sun, 19 May 2013 08:04:00 -0000 Message-ID: <71C49BB0B847984EAADFE43F93C6BF081196EDF2@IL-EX10.ad.checkpoint.com> References: <71C49BB0B847984EAADFE43F93C6BF081196ED31@IL-EX10.ad.checkpoint.com> In-Reply-To: x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean x-cpdlp: 113000dfb610d87c592440f026303a67006c41afec Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-SW-Source: 2013-05/txt/msg00081.txt.bz2 Thanks doug. Of course I have copied the 32bit /usr/lib/libpthread.so.0 to the target m= achine. Yet following your emphasis on this specific file I double checked, and rea= lized the /usr/lib/libpthread.so.o file is merely a text file... not the re= al library. The real 32bit one resides in /lib, not in /usr/lib. Copying /lib/libpthread.so.0 and /lib/libthread_db.so.1 to the target resol= ved the problem. Thanks a lot, Avi -----Original Message----- From: Doug Evans [mailto:dje@google.com]=20 Sent: Thursday, May 16, 2013 7:26 PM To: Avi Gozlan Cc: gdb@sourceware.org Subject: Re: GDB and libthread_db.so.1 issue On Thu, May 16, 2013 at 5:30 AM, Avi Gozlan wrote: > Hello, > > I have got a problem with debugging 32bit applications on a target x86_64= machine. > > I use 64bit gdb 7.1 on a x86_64 machine (running 'file `which gdb`'=20 > returns ELF 64-bit LSB executable, AMD x86-64...) I can debug 64bit appli= cations successfully on this target machine. However, when trying to debug = 32bit applications, I get the following error message: > Cannot find new threads: generic error > > Both libpthread.so.0 and libthread_db.so.1 were copied from another machi= ne, both are located in /lib64. (for the sake of trouble shooting I replace= d also libc.so.6 and ld-linux-x86.so.2 with libraries copied from that same= machine). > > When debugging gdb itself, I saw that indeed these shared libraries are l= oaded by gdb (by running 'info shared'). Yet debugging fails with 32bit pro= grams. The top of the gdb's backtrace for the failure is the following: > > #0 thread_db_err_str (err=3DTD_ERR) at linux-thread-db.c:264 > #1 0x0000000000497897 in find_new_threads_callback (th_p=3D0x7fffffffb76= 0, > data=3D0x7fffffffb840) at linux-thread-db.c:1306 > #2 0x0000003154202000 in iterate_thread_list () from=20 > /lib64/libthread_db.so.1 > #3 0x00000031542020b5 in td_ta_thr_iter () from=20 > /lib64/libthread_db.so.1 > #4 0x0000000000497aea in find_new_threads_once (info=3D0xd38a50, iterati= on=3D0, > errp=3D0x7fffffffb8c0) at linux-thread-db.c:1378 > #5 0x0000000000497ccc in thread_db_find_new_threads_2 (ptid=3D..., > until_no_new=3D0) at linux-thread-db.c:1445 > #6 0x0000000000497d2b in thread_db_find_new_threads_1 (ptid=3D...) > at linux-thread-db.c:1454 > #7 0x00000000004976d9 in thread_db_wait (ops=3D0xb21ca0, ptid=3D..., > ourstatus=3D0x7fffffffbad0, options=3D0) at linux-thread-db.c:1247 > #8 0x0000000000588734 in target_wait (ptid=3D..., status=3D0x7fffffffbad= 0, > options=3D0) at target.c:2132 > #9 0x0000000000551de6 in wait_for_inferior (treat_exec_as_sigtrap=3D0) > at infrun.c:2270 > #10 0x0000000000551468 in proceed (addr=3D18446744073709551615, > siggnal=3DTARGET_SIGNAL_0, step=3D0) at infrun.c:1896 > #11 0x000000000054ad68 in run_command_1 (args=3D0x0, from_tty=3D1, > tbreak_at_main=3D0) at infcmd.c:585 > #12 0x000000000054ad9b in run_command (args=3D0x0, from_tty=3D1) at=20 > infcmd.c:595 > #13 0x00000000004bc730 in do_cfunc (c=3D0xb80070, args=3D0x0, from_tty=3D= 1) > > It appears that the libthread_db library is called by gdb but identifies = a problem. As said, the very same libraries are loaded by gdb for a succes= sful 64bit applications debugging. > > I would be thankful if you could shed light on this issue. It's unfortunate that libthread_db errors aren't more descriptive. I hate = debugging these issues too. Note that libpthread is linked into the app and libthread_db is loaded by g= db. And they need to match. You say you copied libpthread from another machine, but did you *also* copy= the 32-bit version of libpthread from the other machine? Email secured by Check Point