Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Andrew Cagney <ac131313@ges.redhat.com>
To: Daniel Jacobowitz <drow@mvista.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [patch/ob] not_a_breakpoint -> not_a_sw_breakpoint
Date: Fri, 16 Aug 2002 10:34:00 -0000	[thread overview]
Message-ID: <3D5D3787.30005@ges.redhat.com> (raw)
In-Reply-To: <20020816155016.GA27242@nevyn.them.org>

 > Great.  I'm going to have to think about this a little more though; if
 > you look in infrun.c you'll see that this parameter sometimes comes
 > from catchpoints, which is unfortunate since we have nowhere that
 > indicates whether a catchpoint is affected by DECR_PC_AFTER_BREAK or
 > not.

See my e-mail to Kevin.  it decides if 
DECR_PC_AFTER_[SOFTWARE_]BREAK[POINT_TRAP] should be applied.

 > (For i386/Linux, when I'm done with it, I believe that throw and catch
 > catchpoints WILL be affected by decr_pc_after_break.... and that
 > fork/exec/vfork catchpoints WON'T be.  I had to hack around this in my
 > work tree.)

Are throw/catch events implemented using software breakpoints that are 
entered into the breakpoint table?

One of the characteristics of the software single step breakpoints is 
that they are not entered into the breakpoint table.  This is why Joel 
needs to hide them from core GDB :-)

I think fork/exec events can be treated separatly.

enjoy,
Andrew


  reply	other threads:[~2002-08-16 17:34 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-08-16  8:37 Andrew Cagney
2002-08-16  8:49 ` Daniel Jacobowitz
2002-08-16 10:34   ` Andrew Cagney [this message]
2002-08-16 10:38     ` Daniel Jacobowitz
2002-08-16 10:43       ` Andrew Cagney
2002-08-16 10:47         ` Daniel Jacobowitz
2002-08-16 10:53           ` Andrew Cagney
2002-08-16 10:56             ` Daniel Jacobowitz
2002-08-16 11:04               ` Andrew Cagney
2002-08-16  9:43 ` Kevin Buettner
2002-08-16 10:34   ` Andrew Cagney
2002-08-16 11:52     ` Kevin Buettner
2002-08-16 12:34       ` Andrew Cagney
2002-08-16 13:12         ` Kevin Buettner
2002-08-16 13:34           ` Andrew Cagney

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=3D5D3787.30005@ges.redhat.com \
    --to=ac131313@ges.redhat.com \
    --cc=drow@mvista.com \
    --cc=gdb-patches@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