From: Mark Kettenis <mark.kettenis@xs4all.nl>
To: aristovski@qnx.com
Cc: gdb@sources.redhat.com
Subject: Re: [RFC] stepping over permanent breakpoint
Date: Mon, 16 Mar 2009 18:50:00 -0000 [thread overview]
Message-ID: <200903161850.n2GIoZgc021072@brahms.sibelius.xs4all.nl> (raw)
In-Reply-To: <gpm2v2$n1o$1@ger.gmane.org> (message from Aleksandar Ristovski on Mon, 16 Mar 2009 13:40:49 -0400)
> From: Aleksandar Ristovski <aristovski@qnx.com>
> Date: Mon, 16 Mar 2009 13:40:49 -0400
>
> Hello,
>
> When there is a hard-coded breakpoint in code, like in this
> example (for x86):
>
> #include <stdio.h>
>
> int main()
> {
> __asm(" int $0x03\n");
> printf("Hello World\n");
> return 0;
> }
>
> gdb on linux will appear to work correctly.
Well, on Linux, that instruction will not be interpreted as a
permanent breakpoint, just like on QNX.
> However, on systems that do not need pc adjustment after
> break (like QNX) gdb will not be able to step over that
> breakpoint unless user explicitly sets a breakpoint on top
> of it.
The big question here is whether a breakpoint trap instruction should
always be interpreted as a permanent breakpoint in GDB or that it only
gets interpreted as such if you actually tell GDB about it. Up until
now, we've always done the latter. If you don't tell GDB, random
breakpoint trap instructions are handled as normal instructions and
you get to see whatever the architecture/OS does for these
instructions.
> I think that in case of linux it is actually working by
> accident - because kernel does not back-up instruction
> pointer after hard-coded breakpoint instruction was
> executed. Gdb will receive SIGTRAP but will not really know why.
>
> Attached patch fixes this for systems where
> gdbarch_decr_pc_after_break (gdbarch) == 0
If you want to fix things, it should be fixed for *all* systems.
next prev parent reply other threads:[~2009-03-16 18:50 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-16 17:41 Aleksandar Ristovski
2009-03-16 18:22 ` Pedro Alves
2009-03-16 18:55 ` Aleksandar Ristovski
2009-03-16 19:38 ` Pedro Alves
2009-03-16 20:37 ` Aleksandar Ristovski
2009-03-16 18:50 ` Mark Kettenis [this message]
2009-03-16 19:04 ` Aleksandar Ristovski
2009-03-23 16:50 ` RFC: Program Breakpoints (was: [RFC] stepping over permanent breakpoint) Ross Morley
2009-03-24 16:57 ` Daniel Jacobowitz
2009-03-24 20:33 ` RFC: Program Breakpoints Ross Morley
2009-03-24 20:40 ` Daniel Jacobowitz
2009-03-24 23:48 ` Pedro Alves
2009-03-25 7:58 ` Mark Kettenis
2009-03-25 13:17 ` Pedro Alves
2009-03-24 23:59 ` Ross Morley
2009-03-31 0:44 ` Ross Morley
2009-03-31 3:17 ` Daniel Jacobowitz
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=200903161850.n2GIoZgc021072@brahms.sibelius.xs4all.nl \
--to=mark.kettenis@xs4all.nl \
--cc=aristovski@qnx.com \
--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