From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23716 invoked by alias); 26 Nov 2007 19:16:43 -0000 Received: (qmail 23704 invoked by uid 22791); 26 Nov 2007 19:16:41 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 26 Nov 2007 19:16:37 +0000 Received: (qmail 1681 invoked from network); 26 Nov 2007 19:16:35 -0000 Received: from unknown (HELO 172.16.unknown.plus.ru) (vladimir@127.0.0.2) by mail.codesourcery.com with ESMTPA; 26 Nov 2007 19:16:35 -0000 From: Vladimir Prus To: Michael Snyder Subject: Re: Questionable breakpoint stepping code Date: Mon, 26 Nov 2007 19:16:00 -0000 User-Agent: KMail/1.9.6 Cc: gdb@sources.redhat.com References: <1196102967.2501.29.camel@localhost.localdomain> In-Reply-To: <1196102967.2501.29.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200711262216.27906.vladimir@codesourcery.com> 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/msg00231.txt.bz2 On Monday 26 November 2007 21:49:27 Michael Snyder wrote: > 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. Yes, I know that. > > You need to do a kind of special single-step to get past that > particular breakpoint, then return to the single-stepping > infrun state. Right. > 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. I know that too. > > As for your last question, no, I don't believe we approve > of ifdefs... Well, the question, then is -- how do we make this code work correctly even if the instruction at PC is not 4 bytes in size? Calling disassembler seems a plausible approach. - Volodya