From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17858 invoked by alias); 10 Aug 2004 20:44:48 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 17850 invoked from network); 10 Aug 2004 20:44:47 -0000 Received: from unknown (HELO e35.co.us.ibm.com) (32.97.110.133) by sourceware.org with SMTP; 10 Aug 2004 20:44:47 -0000 Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e35.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id i7AKiiu3075466; Tue, 10 Aug 2004 16:44:44 -0400 Received: from austin.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by westrelay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i7AKig0c165900; Tue, 10 Aug 2004 14:44:43 -0600 Received: from lazy.austin.ibm.com (lazy.austin.ibm.com [9.53.94.97]) by austin.ibm.com (8.12.10/8.12.10) with ESMTP id i7AKigSZ063452; Tue, 10 Aug 2004 15:44:42 -0500 Date: Tue, 10 Aug 2004 20:44:00 -0000 From: Manoj Iyer X-X-Sender: manjo@lazy To: Andrew Cagney cc: gilliam@us.ibm.com, gdb-patches@sources.redhat.com Subject: Re: [RFC] New thread testcase. In-Reply-To: <411930DF.30401@gnu.org> Message-ID: References: <4117F82B.nail1N111PN0T@mindspring.com> <41187827.nailB8H1E9AWV@mindspring.com> <4118E61B.3060902@gnu.org> <411930DF.30401@gnu.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2004-08/txt/msg00373.txt.bz2 oh! sorry abt that... got confused btwn 'bugs'... The kernel bug was causing gdb to fail when passing a 32bit address to the kernel. this was causing 32 bit gdb to fail in linux_test_for_tracefork() by always returning second_pid = 0 in the PTRACE_GETEVENTMSG call. this resulted in linux_enable_event_reporting() not setting the PTRACE fork options for the pid and then the thread never received a SIGSTOP. John Engel, kernel developer, debugged and fixed this problem in the kernel after we reported this GDB problem to him... So, when you debug a multi-threaded app with 32bit GDB on a PPC64 system, and you set a break point at the thread function and tried to step, you get the message "reading register pc (#64): No such process." for example: Breakpoint 1, main (argc=1, argv=0xffffe464) at tbug.c:31 31 for (n = 0; n < N; ++n) (gdb) cont Continuing. [New Thread 1078217504 (LWP 26708)] tf(0): begin [New Thread 1082411808 (LWP 26709)] after create tf(1): begin tf(0): end [Thread 1078217504 (LWP 26708) exited] tf(1): end [Thread 1082411808 (LWP 26709) exited] after join Program exited normally. (gdb) clear main Deleted breakpoint 1 (gdb) break tf Breakpoint 2 at 0x10000594: file tbug.c, line 15. (gdb) run Starting program: /home/public/test-tools/gdb/tbug [Thread debugging using libthread_db enabled] [New Thread 1074020384 (LWP 26710)] reading register pc (#64): No such process. (gdb) cont Continuing. reading register pc (#64): No such process. Thanks ----- ---- Manoj Iyer +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + Cognito ergo sum + +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ On Tue, 10 Aug 2004, Andrew Cagney wrote: > >>Manoj, > >>> > >>> You've got me curious. Do any of the existing tests exercise this bug > >>> (manythreads.exp comes to mind)? Oh, and what is the bug? :-) > >>> > > > > > > This is a generic kernel bug (in ptrace() )that causes ptrace to fail on > > Power 64 systems. Please look at PR#1712 for details. > > Unfortunatly 1712 doesn't answer my question. What is the bug? What > causes ptrace to fail? > > Andrew > > >