From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11404 invoked by alias); 6 May 2009 18:58:21 -0000 Received: (qmail 11380 invoked by uid 22791); 6 May 2009 18:58:19 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 06 May 2009 18:57:45 +0000 Received: (qmail 7519 invoked from network); 6 May 2009 18:57:43 -0000 Received: from unknown (HELO orlando.local) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 6 May 2009 18:57:43 -0000 From: Pedro Alves To: Joel Brobecker Subject: Re: [RFC] Remove last occurences of target_{insert/remove}_watchpoint Date: Wed, 06 May 2009 18:58:00 -0000 User-Agent: KMail/1.9.10 Cc: gdb-patches@sourceware.org, Pierre Muller References: <001a01c9c39f$e3f217c0$abd64740$@u-strasbg.fr> <200905061814.57665.pedro@codesourcery.com> <20090506183542.GQ10734@adacore.com> In-Reply-To: <20090506183542.GQ10734@adacore.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200905061958.26007.pedro@codesourcery.com> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2009-05/txt/msg00132.txt.bz2 On Wednesday 06 May 2009 19:35:42, Joel Brobecker wrote: > Yeah, I have roughly the same number of hits for that one. > That leaves another thousand of so errors. As far as I can tell, > they are made of several different symptoms: ~100 internal-errors, > about a 100 are caused by the fact that we failed to run the program > or ran the program to completion, etc etc etc. I think that those other problems may be related to the issue I mentioned on IRC the other day. The fact that the procfs.c code that sets a breakpoint at __dbx_link during the startup phase is broken. I'll paste it here for posterity. :-) - That breakpoint was set during the startup phase by catching syscall-exits during the startup phase, more precisely, during the phase that the inferior is ran through the dynamic linker in solib_create_inferior_hook -> irix_solib_create_inferior_hook. This was done by enabling PR_SYSEXIT syscall tracing in procfs_init_inferior, and disabling after fork_inferior returned. Look for SYS_syssgi in procfs.c to see this. This worked because many moons ago, at the time that code was written, fork_inferior used to call solib_create_inferior_hook before returning. http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/fork-child.c.diff?r1=1.28&r2=1.27.6.1&cvsroot=src&f=h - Problem is, that now, solib_create_inferior is only called *after* all of this, in post_create_inferior. So the wrapping to catch syscall-exits is being done at the wrong place. - You probably need to delay disabling catching syscall-exits/looking for __dbx_link into the inferior_created observer, instead of disabling it at the end of procfs_create_inferior. > I can send you the gdb.log file if you're interested. I suspect not ;-). Not. :-) -- Pedro Alves