From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5198 invoked by alias); 16 May 2013 16:26:25 -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 5177 invoked by uid 89); 16 May 2013 16:26:25 -0000 X-Spam-SWARE-Status: No, score=-4.2 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.1 Received: from mail-vb0-f46.google.com (HELO mail-vb0-f46.google.com) (209.85.212.46) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Thu, 16 May 2013 16:26:24 +0000 Received: by mail-vb0-f46.google.com with SMTP id 10so1554888vbe.33 for ; Thu, 16 May 2013 09:26:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=5naMpdZF9tk71XtcEa4L6bmXD83H4Kb42pe82HnlcV8=; b=CIZrcyqG6gThni05q6mOyxf8fQtRDDn1Pn9j1qz9CKvqkbOwqA7/fS5zUFx+d1Scnv RsCLqQ7VYM7kd9yKHxtj+xi3Pr8Tpvypg1pJXnK/NU0uKOxIjlnb5oA/b3sHoKlSOR1y h6/6Qf27ccaK4bFzvM1mGI4Ju6NiRQoF59VYKOXjzNV9Y4S9rQOJVHsvODbvuvrwbp/s jcOCAweXEslcwnLqbBwmKolgnOMjdC2s/CGmtvz0PGT4D1Kr87zyq2C53UQOHbTbZKBi 71fqXjGnHR+TmE0NO+eJZNWbVYDn14JJUEPmeiyfVCfifU+t6JP5+uF3pOH2wc6jCgPp 60jw== MIME-Version: 1.0 X-Received: by 10.52.183.170 with SMTP id en10mr24249794vdc.5.1368721582337; Thu, 16 May 2013 09:26:22 -0700 (PDT) Received: by 10.220.54.75 with HTTP; Thu, 16 May 2013 09:26:22 -0700 (PDT) In-Reply-To: <71C49BB0B847984EAADFE43F93C6BF081196ED31@IL-EX10.ad.checkpoint.com> References: <71C49BB0B847984EAADFE43F93C6BF081196ED31@IL-EX10.ad.checkpoint.com> Date: Thu, 16 May 2013 16:26:00 -0000 Message-ID: Subject: Re: GDB and libthread_db.so.1 issue From: Doug Evans To: Avi Gozlan Cc: "gdb@sourceware.org" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQk8rMyXWzRYkiJftVMGUsqI1f9m4AVjGxcs2ys2N2NezTYeLiXXaIUEtTZ774OAlr5y47dpZj6wzm8/ss7lIj2SOiq9phFXkSA38bvpNp5w8vK/kPHf33sDX+S/noZZByTe31PqyCnC3y5exGXhZQE+SJrK7DZ/8b/JBYwdNTsbrj8BQO3eI+/G+5BaSRpei9gJJKx6 X-SW-Source: 2013-05/txt/msg00073.txt.bz2 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`' returns ELF 64-bit LSB executable, AMD x86-64...) > I can debug 64bit applications 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 machine, both are located in /lib64. (for the sake of trouble shooting I replaced 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 loaded by gdb (by running 'info shared'). Yet debugging fails with 32bit programs. The top of the gdb's backtrace for the failure is the following: > > #0 thread_db_err_str (err=TD_ERR) at linux-thread-db.c:264 > #1 0x0000000000497897 in find_new_threads_callback (th_p=0x7fffffffb760, > data=0x7fffffffb840) at linux-thread-db.c:1306 > #2 0x0000003154202000 in iterate_thread_list () from /lib64/libthread_db.so.1 > #3 0x00000031542020b5 in td_ta_thr_iter () from /lib64/libthread_db.so.1 > #4 0x0000000000497aea in find_new_threads_once (info=0xd38a50, iteration=0, > errp=0x7fffffffb8c0) at linux-thread-db.c:1378 > #5 0x0000000000497ccc in thread_db_find_new_threads_2 (ptid=..., > until_no_new=0) at linux-thread-db.c:1445 > #6 0x0000000000497d2b in thread_db_find_new_threads_1 (ptid=...) > at linux-thread-db.c:1454 > #7 0x00000000004976d9 in thread_db_wait (ops=0xb21ca0, ptid=..., > ourstatus=0x7fffffffbad0, options=0) at linux-thread-db.c:1247 > #8 0x0000000000588734 in target_wait (ptid=..., status=0x7fffffffbad0, > options=0) at target.c:2132 > #9 0x0000000000551de6 in wait_for_inferior (treat_exec_as_sigtrap=0) > at infrun.c:2270 > #10 0x0000000000551468 in proceed (addr=18446744073709551615, > siggnal=TARGET_SIGNAL_0, step=0) at infrun.c:1896 > #11 0x000000000054ad68 in run_command_1 (args=0x0, from_tty=1, > tbreak_at_main=0) at infcmd.c:585 > #12 0x000000000054ad9b in run_command (args=0x0, from_tty=1) at infcmd.c:595 > #13 0x00000000004bc730 in do_cfunc (c=0xb80070, args=0x0, from_tty=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 successful 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 gdb. 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?