From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-return-30311-listarch-gdb=sources.redhat.com@sourceware.org>
Received: (qmail 12096 invoked by alias); 23 Nov 2007 14:06:00 -0000
Received: (qmail 12087 invoked by uid 22791); 23 Nov 2007 14:05:58 -0000
X-Spam-Check-By: sourceware.org
Received: from main.gmane.org (HELO ciao.gmane.org) (80.91.229.2)     by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 23 Nov 2007 14:05:52 +0000
Received: from list by ciao.gmane.org with local (Exim 4.43) 	id 1IvZ8y-0006gW-NX 	for gdb@sources.redhat.com; Fri, 23 Nov 2007 14:04:32 +0000
Received: from 77.246.241.246 ([77.246.241.246])         by main.gmane.org with esmtp (Gmexim 0.1 (Debian))         id 1AlnuQ-0007hv-00         for <gdb@sources.redhat.com>; Fri, 23 Nov 2007 14:04:32 +0000
Received: from ghost by 77.246.241.246 with local (Gmexim 0.1 (Debian))         id 1AlnuQ-0007hv-00         for <gdb@sources.redhat.com>; Fri, 23 Nov 2007 14:04:32 +0000
To: gdb@sources.redhat.com
From:  Vladimir Prus <ghost@cs.msu.su>
Subject:  Questionable breakpoint stepping code
Date: Fri, 23 Nov 2007 14:06:00 -0000
Message-ID:  <fi6m64$qav$1@ger.gmane.org>
Mime-Version:  1.0
Content-Type:  text/plain; charset=us-ascii
Content-Transfer-Encoding:  7Bit
User-Agent: KNode/0.10.4
X-IsSubscribed: yes
Mailing-List: contact gdb-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <gdb.sourceware.org>
List-Subscribe: <mailto:gdb-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb/>
List-Post: <mailto:gdb@sourceware.org>
List-Help: <mailto:gdb-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: gdb-owner@sourceware.org
X-SW-Source: 2007-11/txt/msg00223.txt.bz2


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