public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
From: Vladimir Prus <ghost@cs.msu.su>
To: gdb@sources.redhat.com
Subject: Questionable breakpoint stepping code
Date: Fri, 23 Nov 2007 14:06:00 -0000	[thread overview]
Message-ID: <fi6m64$qav$1@ger.gmane.org> (raw)


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


             reply	other threads:[~2007-11-23 14:06 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-11-23 14:06 Vladimir Prus [this message]
2007-11-26 19:01 ` Michael Snyder
2007-11-26 19:16   ` Vladimir Prus
2007-11-26 19:24     ` Daniel Jacobowitz
2007-11-26 19:28     ` Michael Snyder
2007-11-27 13:50       ` Vladimir Prus
2007-11-27 13:54         ` Daniel Jacobowitz
2007-11-27 19:33           ` Joel Brobecker
2007-11-29 12:35             ` Vladimir Prus
2007-11-30  1:14               ` Joel Brobecker
2007-11-30 11:48                 ` Vladimir Prus
2007-12-13 16:09                   ` Vladimir Prus
2008-01-17  1:13                     ` Jim Blandy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='fi6m64$qav$1@ger.gmane.org' \
    --to=ghost@cs.msu.su \
    --cc=gdb@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).