From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12034 invoked by alias); 20 Sep 2011 23:22:40 -0000 Received: (qmail 12025 invoked by uid 22791); 20 Sep 2011 23:22:39 -0000 X-SWARE-Spam-Status: No, hits=-1.3 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,TW_XF X-Spam-Check-By: sourceware.org Received: from phx-mxvgateway.goodrich.com (HELO phx-mxv2gateway.goodrich.com) (63.241.174.110) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 20 Sep 2011 23:22:25 +0000 Received: from GR-GWI-WEST-A.goodrich.com (gr-gwi-west-a.goodrich.com [170.126.245.4]) by phx-mxv2gateway.goodrich.com (Symantec Messaging Gateway) with SMTP id 11.6B.23832.030297E4; Tue, 20 Sep 2011 19:22:24 -0400 (EDT) Received: from nhc0ex21.goodrich.root.local ([170.126.245.60]) by GR-GWI-WEST-A.goodrich.com (8.13.5/8.13.5) with ESMTP id p8KNMObR022565; Tue, 20 Sep 2011 19:22:24 -0400 (EDT) Received: from nhc0ex17.goodrich.root.local ([170.126.246.106]) by nhc0ex21.goodrich.root.local with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Sep 2011 16:22:24 -0700 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: fail to attach to process on Solaris Date: Tue, 20 Sep 2011 23:22:00 -0000 Message-ID: In-Reply-To: <201109022224.29804.pedro@codesourcery.com> References: <201109022224.29804.pedro@codesourcery.com> From: "Burkhardt, Glenn" To: "Pedro Alves" , 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 X-SW-Source: 2011-09/txt/msg00076.txt.bz2 The problem appears that thread debug library has callback for register get operation that's connected to "sol-thread.c:ps_lgetregs()". In the case that fails, the thread exists, but the calling sequence tries to lookup registers for a LWP with the same ID as the thread. #0 find_procinfo_or_die (pid=3D12276, tid=3D67) at procfs.c:489 #1 0x000a1cd0 in procfs_fetch_registers (ops=3D0x7293d8, regcache=3D0x71b1d0,=20 regnum=3D-1) at procfs.c:3483 #2 0x0012feec in sol_thread_fetch_registers (ops=3D0x718a70, regcache=3D0x71b1d0,=20 regnum=3D-1) at sol-thread.c:457 #3 0x00231af0 in target_fetch_registers (regcache=3D0x71b1d0, regno=3D-1) at target.c:3417 #4 0x00130e48 in ps_lgetregs (ph=3D0x700998, lwpid=3D67, gregset=3D0xffbfe37c) at sol-thread.c:923 #5 0xff0735dc in td_thr_getgregs () from /usr/lib/libthread_db.so.1 #6 0x0012fff8 in sol_thread_fetch_registers (ops=3D0x718a70, regcache=3D0x71b3b0,=20 regnum=3D68) at sol-thread.c:473=20 For this stack trace of 'gdb', 'sol_thread_fetch_registers()' is passed=20 (gdb) frame #6 0x0012fff8 in sol_thread_fetch_registers (ops=3D0x718a70, regcache=3D0x71b3b0,=20 regnum=3D68) at sol-thread.c:473 473 val =3D p_td_thr_getgregs (&thandle, gregset); (gdb) p *regcache $24 =3D {descr =3D 0x84fc40, aspace =3D 0x7aa258, registers =3D 0x846c48 ""= ,=20 register_status =3D 0x14f37c0 "", readonly_p =3D 0, ptid =3D {pid =3D 122= 76,=20 lwp =3D 0, tid =3D 67}} So it's looking for registers from a thread that's not associated with an LWP. But the function 'ps_lgetregs()' is always looking for the registers on the LWP list. I can't see how the callback 'ps_lgetregs()' is connected to the thread debug library. In fact, the documentation for the thread debug library seems sparse. I've only been able to find out about it in the man pages and comments section of sol-thread.c So any pointers to documentation would be helpful. Also, any theory of operation about gdb's register caching would also be helpful. Thanks. > -----Original Message----- > From: Pedro Alves [mailto:pedro@codesourcery.com]=20 > Sent: Friday, September 02, 2011 5:24 PM > To: gdb@sourceware.org > Cc: Burkhardt, Glenn > Subject: Re: fail to attach to process on Solaris >=20 >=20 > On Monday 22 August 2011 16:05:10, Burkhardt, Glenn wrote: > > I can't seem to attach to a process that's running multiple threads. > > Any help is appreciated. I've included the print output from the=20 > > whole session, but the problem is the line: > >=20 > > procfs: couldn't find pid 15719 (kernel thread 67) in procinfo list. >=20 > Been a while since I looked at the solaris backend, so I=20 > can't help much off hand. I'm affraid you'll need to debug=20 > this yourself. > Starting with "set debug infrun 1" may help. I'd start by=20 > understanding why does gdb think 67 should be in the list. >=20 > -- > Pedro Alves >=20