From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9410 invoked by alias); 22 Apr 2010 16:51:01 -0000 Received: (qmail 9281 invoked by uid 22791); 22 Apr 2010 16:50:58 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,T_RP_MATCHES_RCVD,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: sourceware.org Received: from mail.gmx.net (HELO mail.gmx.net) (213.165.64.20) by sourceware.org (qpsmtpd/0.43rc1) with SMTP; Thu, 22 Apr 2010 16:50:50 +0000 Received: (qmail invoked by alias); 22 Apr 2010 16:50:46 -0000 Received: from p3E9E63DA.dip.t-dialin.net (EHLO licht.localdomain) [62.158.99.218] by mail.gmx.net (mp009) with SMTP; 22 Apr 2010 18:50:46 +0200 Received: from licht.localdomain (localhost.localdomain [127.0.0.1]) by licht.localdomain (8.12.8/8.12.8) with ESMTP id o3MGoh0E021292; Thu, 22 Apr 2010 18:50:44 +0200 Received: (from pes@localhost) by licht.localdomain (8.12.8/8.12.8/Submit) id o3MGogV2021289; Thu, 22 Apr 2010 18:50:42 +0200 From: Peter Schauer Message-Id: <201004221650.o3MGogV2021289@licht.localdomain> Subject: Re: Question about solaris CANNOT_STEP_HW_WATCHPOINTS macro To: pierre.muller@ics-cnrs.unistra.fr (Pierre Muller) Date: Thu, 22 Apr 2010 16:51:00 -0000 Cc: brobecker@adacore.com ('Joel Brobecker'), Peter.Schauer@regent.e-technik.tu-muenchen.de, gdb@sourceware.org, pieter.maljaars@altenpts.nl ('Pieter Maljaars'), joseph@codesourcery.com ('Joseph S. Myers'), pedro@codesourcery.com ('Pedro Alves') In-Reply-To: <003101cae232$e2564ff0$a702efd0$@muller@ics-cnrs.unistra.fr> from "Pierre Muller" at Apr 22, 2010 05:45:49 PM MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit 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: 2010-04/txt/msg00082.txt.bz2 Thanks Pierre, you are describing the problem perfectly well. According to my notes the problem caused FAIL: gdb.base/watchpoint.exp: until to ival1 assignment FAIL: gdb.base/watchpoint.exp: until to ival3 assignment FAIL: gdb.base/watchpoint.exp: until out of loop FAIL: gdb.base/watchpoint.exp: step to ival2 assignment regressions, but your example should trigger the problem as well. IIRC, it happened on x86 Solaris 2.6 and early 2.7 systems, and was fixed in 2.8 systems. Unfortunately I have no longer access to any Solaris system, so I can't be of any help here. Sorry, > > -----Message d'origine----- > > De : gdb-owner@sourceware.org [mailto:gdb-owner@sourceware.org] De la > > part de Joel Brobecker > > Envoyé : Thursday, April 22, 2010 3:57 PM > > À : Pierre Muller > > Cc : gdb@sourceware.org; 'Pieter Maljaars'; 'Joseph S. Myers'; 'Pedro > > Alves' > > Objet : Re: Question about solaris CANNOT_STEP_HW_WATCHPOINTS macro > > > > > The macro CANNOT_STEP_HW_WATCHPOINTS > > [...] > > > If this bug has been solve before 2.9 version of Solaris, > > > would it be reasonable to just drop that code out? > > > > I think we should still support version 2.8 if we can. > > I have no objections > > > I'd be happy to do any testing with some of our machines running > > Solaris, > > but I need a reproducer that I can run by hand. I am still under > > strict > > orders to *NOT* run the dejagnu testsuite on our solaris machines, as > > it > > causes them to crash pretty badly :-(. > The main problem is that the comment inside > infrun.c is not that clear... > > The patch was discussed in 2000: > http://sourceware.org/ml/gdb-patches/2000-q1/msg00664.html > submitted by Peter Schauer. > But I don't know if this person still is reachable. > I suspect that the problem appears if > 1) you are stepping > 2) you have a watchpoint on some memory location > 3) you modify some other location within the same > protected page. > The kernel stops because of the page protection, > sees that the accessed address is not the one you asked to > watch, thus restarts the debuggee, forgetting that > stepping was required. > > This is at least how I understood it. > > The problem is that I have no access > to a machine for which we can be sure that this bug > still exists ... > > With this source > struct rec > { > int x; > double y; > int z; > }; > > static struct rec myrec; > > int > main () > { > myrec.x = 5; > myrec.y = 3.4; > myrec.z = 56; > myrec.x = 78; > return myrec.x; > } > > setting a watchpoint on myrec.x and > stepping should expose the bug if you > remove the CANNOT_STEP_HW_WATCHPOINT from nm-i386sol2.h > > > Pierre -- Peter Schauer Peter.Schauer@mytum.de