From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31284 invoked by alias); 27 Aug 2004 13:48:30 -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 31237 invoked from network); 27 Aug 2004 13:48:27 -0000 Received: from unknown (HELO e35.co.us.ibm.com) (32.97.110.133) by sourceware.org with SMTP; 27 Aug 2004 13:48:27 -0000 Received: from westrelay03.boulder.ibm.com (westrelay03.boulder.ibm.com [9.17.195.12]) by e35.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id i7RDmI06352272; Fri, 27 Aug 2004 09:48:18 -0400 Received: from austin.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by westrelay03.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i7RDmGgu380478; Fri, 27 Aug 2004 07:48:18 -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 i7RDmERn049662; Fri, 27 Aug 2004 08:48:15 -0500 Date: Fri, 27 Aug 2004 13:48:00 -0000 From: Manoj Iyer X-X-Sender: manjo@lazy To: Michael Snyder cc: Andrew Cagney , gilliam@us.ibm.com, gdb-patches@sources.redhat.com Subject: Re: [RFC] New thread testcase. In-Reply-To: <412EA96D.8010307@redhat.com> Message-ID: References: <4117F82B.nail1N111PN0T@mindspring.com> <41187827.nailB8H1E9AWV@mindspring.com> <4118E61B.3060902@gnu.org> <411930DF.30401@gnu.org> <412EA96D.8010307@redhat.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2004-08/txt/msg00730.txt.bz2 Yes you are correct, I did note the same I can modify the testcase and and incorporate other suggestions as well. Will that qualify for acceptance? Thanks ----- manjo +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + Cognito ergo sum + +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ On Fri, 27 Aug 2004, Michael Snyder wrote: > Manoj, > > It sounds from your eplanation like the "step" part of your test > is not required, since your bug shows up without it. I explained > in my previous msg why I was concerned about that test. What > would you think of removing the step? > > Michael > > Manoj Iyer wrote: > > 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 > >> > >> > >> > > > > > > >