From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16765 invoked by alias); 23 Apr 2010 00:56:13 -0000 Received: (qmail 16753 invoked by uid 22791); 23 Apr 2010 00:56:12 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 23 Apr 2010 00:56:07 +0000 Received: (qmail 11922 invoked from network); 23 Apr 2010 00:56:05 -0000 Received: from unknown (HELO orlando.localnet) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 23 Apr 2010 00:56:05 -0000 From: Pedro Alves To: Joel Brobecker Subject: Re: Question about solaris CANNOT_STEP_HW_WATCHPOINTS macro Date: Fri, 23 Apr 2010 00:56:00 -0000 User-Agent: KMail/1.12.2 (Linux/2.6.31-20-generic; KDE/4.3.2; x86_64; ; ) Cc: Pierre Muller , Peter.Schauer@regent.e-technik.tu-muenchen.de, gdb@sourceware.org, "'Pieter Maljaars'" , "'Joseph S. Myers'" References: <001501cad820$36771f50$a3655df0$@muller@ics-cnrs.unistra.fr> <003101cae232$e2564ff0$a702efd0$@muller@ics-cnrs.unistra.fr> <20100422235956.GG13204@adacore.com> In-Reply-To: <20100422235956.GG13204@adacore.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201004230156.03303.pedro@codesourcery.com> X-IsSubscribed: yes 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/msg00089.txt.bz2 On Friday 23 April 2010 00:59:56, Joel Brobecker wrote: > > setting a watchpoint on myrec.x and > > stepping should expose the bug if you > > remove the CANNOT_STEP_HW_WATCHPOINT from nm-i386sol2.h > > Looks like a different bug is now occurring: ... > Looking at the infrun debug output: > > (gdb) set debug infrun 1 > (gdb) s > infrun: clear_proceed_status_thread (LWP 1) > infrun: proceed (addr=0xffffffff, signal=144, step=1) > infrun: resume (step=1, signal=0), trap_expected=0 > infrun: wait_for_inferior (treat_exec_as_sigtrap=0) > infrun: target_wait (-1, status) = > infrun: 3497 [LWP 1], > infrun: status->kind = stopped, signal = SIGTRAP > infrun: infwait_normal_state > infrun: TARGET_WAITKIND_STOPPED > infrun: stop_pc = 0x8050684 > infrun: stepped to a different line > infrun: stop_stepping > 14 myrec.y = 3.4; > > So we failed to notice that the watchpoint triggered - we should probably > look in the area of procfs_stopped_by_watchpoint. Maybe another kernel > issue??? I think older GDBs handled this because they always checked for watchpoint hits at every SIGTRAP. Notice the comment in infrun.c: > /* Some targets (e.g. Solaris x86) have a kernel bug when stepping > over an instruction that causes a page fault without triggering > a hardware watchpoint. The kernel properly notices that it shouldn't > stop, because the hardware watchpoint is not triggered, but it forgets > the step request and continues the program normally. > Work around the problem by removing hardware watchpoints if a step is > requested, GDB will check for a hardware watchpoint trigger after the ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > step anyway. */ ^^^^^^^^^^^ That underlined part of the comment is no longer true nowadays. See PR9633 , which points at some other target relying on it. > If I use the "continue" command instead of a step, the infrun debug > output looks like this: > > (gdb) cont > Continuing. > infrun: clear_proceed_status_thread (LWP 1) > infrun: proceed (addr=0xffffffff, signal=144, step=0) > infrun: resume (step=0, signal=0), trap_expected=0 > infrun: wait_for_inferior (treat_exec_as_sigtrap=0) > infrun: target_wait (-1, status) = > infrun: 3524 [LWP 1], > infrun: status->kind = stopped, signal = SIGTRAP > infrun: infwait_normal_state > infrun: TARGET_WAITKIND_STOPPED > infrun: stop_pc = 0x8050684 > infrun: stopped by watchpoint <<<<<--------- > infrun: (no data address available) > infrun: BPSTAT_WHAT_STOP_NOISY > infrun: stop_stepping > Hardware watchpoint 2: myrec.x > > Old value = 0 > New value = 5 > main () at foo.c:14 > 14 myrec.y = 3.4; > > I ran watchpoint.exp alone and the testcase passes without any problem. > > One last thing: It does not make any difference whether the > CANNOT_STEP_HW_WATCHPOINT macro is defined or not. So, I think that, > starting with version 2.8, it's safe to not have it defined. Do we still care for <= 2.7 at this point? (and before someone spontaneously says "yes"; does GDB still work okay on such old Solaris systems?) -- Pedro Alves