From: Eli Zaretskii <eliz@elta.co.il>
To: Andrew Cagney <cagney@gnu.org>
Cc: kettenis@chello.nl, gdb@sources.redhat.com
Subject: Re: [RFC] Non-executable stack on SPARC
Date: Tue, 27 Jan 2004 08:00:00 -0000 [thread overview]
Message-ID: <u8yjtom6g.fsf@elta.co.il> (raw)
In-Reply-To: <40153E6D.2050805@gnu.org> (message from Andrew Cagney on Mon, 26 Jan 2004 11:21:01 -0500)
> Date: Mon, 26 Jan 2004 11:21:01 -0500
> From: Andrew Cagney <cagney@gnu.org>
>
> A more robust check would be to confirm that a breakpoint is at that
> address (naturally ignoring decr pc after break :-).
If we can do that, why do we also test the signal that was reported
when the inferior stopped? What you say sounds like it would be
enough to verify that the place where it stopped has a breakpoint, and
decide right there and then that it stopped because the breakpoint
breaks, no matter what TARGET_SIGNAL_* was reported.
> > 2. Add a new method to the architecture vector to check whether a
> > particular signal may have been the result of a breakpoint
> > instruction. Suggested name & signature:
> >
> > int breakpoint_signal_p (struct gdbarch *gdbarch, int signal)
>
> For this, that would be wrong. The target, in combination with the
> breakpoint code, determines if a breakpoint leads to a sigsegv.
I'm not sure I understand: are you saying that this is a target
issue, not an architecture issue?
next prev parent reply other threads:[~2004-01-27 8:00 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-01-25 23:50 Mark Kettenis
2004-01-25 23:59 ` Daniel Jacobowitz
2004-01-26 6:51 ` Eli Zaretskii
2004-01-26 6:51 ` Eli Zaretskii
2004-01-26 12:42 ` Mark Kettenis
2004-01-27 8:16 ` Eli Zaretskii
2004-02-01 17:48 ` Mark Kettenis
2004-02-01 20:13 ` Eli Zaretskii
2004-02-02 18:37 ` Andrew Cagney
2004-01-26 16:21 ` Andrew Cagney
2004-01-27 8:00 ` Eli Zaretskii [this message]
2004-02-01 17:54 ` Mark Kettenis
2004-02-02 18:27 ` 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=u8yjtom6g.fsf@elta.co.il \
--to=eliz@elta.co.il \
--cc=cagney@gnu.org \
--cc=gdb@sources.redhat.com \
--cc=kettenis@chello.nl \
/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