From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5322 invoked by alias); 26 Nov 2007 19:01:47 -0000 Received: (qmail 5230 invoked by uid 22791); 26 Nov 2007 19:01:46 -0000 X-Spam-Check-By: sourceware.org Received: from bluesmobile.specifix.com (HELO bluesmobile.specifix.com) (216.129.118.140) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 26 Nov 2007 19:01:42 +0000 Received: from [127.0.0.1] (bluesmobile.specifix.com [216.129.118.140]) by bluesmobile.specifix.com (Postfix) with ESMTP id 053E73C124; Mon, 26 Nov 2007 10:40:04 -0800 (PST) Subject: Re: Questionable breakpoint stepping code From: Michael Snyder To: Vladimir Prus Cc: gdb@sources.redhat.com In-Reply-To: References: Content-Type: text/plain Date: Mon, 26 Nov 2007 19:01:00 -0000 Message-Id: <1196102967.2501.29.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.10.3 (2.10.3-4.fc7) Content-Transfer-Encoding: 7bit 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: 2007-11/txt/msg00227.txt.bz2 On Fri, 2007-11-23 at 16:56 +0300, Vladimir Prus wrote: > The infrun.c:handle_inferiour_event function has > this code block: > > if (thread_hop_needed) > { > ........ > remove_status = remove_breakpoints (); > /* Did we fail to remove breakpoints? If so, try > to set the PC past the bp. (There's at least > one situation in which we can fail to remove > the bp's: On HP-UX's that use ttrace, we can't > change the address space of a vforking child > process until the child exits (well, okay, not > then either :-) or execs. */ > if (remove_status != 0) > { > /* FIXME! This is obviously non-portable! */ > write_pc_pid (stop_pc + 4, ecs->ptid); > /* We need to restart all the threads now, > * unles we're running in scheduler-locked mode. > * Use currently_stepping to determine whether to > * step or continue. > */ > /* FIXME MVS: is there any reason not to call resume()? */ > if (scheduler_mode == schedlock_on) > target_resume (ecs->ptid, > currently_stepping (ecs), TARGET_SIGNAL_0); > else > target_resume (RESUME_ALL, > currently_stepping (ecs), TARGET_SIGNAL_0); > prepare_to_wait (ecs); > return; > } > > The code is a bit scary -- specifically I sure don't want GDB to mess > with PC values like this on x86, if removing breakpoints fails in any way. > The essential bits of this code are present as of revision 1.1 of infrun.c > (added in 1999). > > So: > 1. Anybody knows if this code is still needed for modern HPUX? > 2. Can we have it wrapped in #ifdef, and if so, which one? > > - Volodya Hi Volodya, I think it's my code. It's not really related specifically to HPUX, that comment was there in the previous iteration and I just kept it. The several state variables with "thread_hop" as part of their names are related to single-stepping in the presence of thread- specific breakpoints. They are meant to solve the problem of what to do if you are doing a step, and you hit a thread-specific breakpoint, but with the wrong thread. You need to do a kind of special single-step to get past that particular breakpoint, then return to the single-stepping infrun state. As for the scheduler-locking code, that pertains to a different but not wholly unrelated functionality (set scheduler-locking), which affects which threads can run at which times. As for your last question, no, I don't believe we approve of ifdefs... Cheers, Michael