This is the mail archive of the
mailing list for the GDB project.
Re: [RFC] stepping over permanent breakpoint
Mark Kettenis wrote:
From: Aleksandar Ristovski <firstname.lastname@example.org>
Date: Mon, 16 Mar 2009 13:40:49 -0400
When there is a hard-coded breakpoint in code, like in this
example (for x86):
__asm(" int $0x03\n");
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.
Except on QNX gdb will not be able to continue or step over
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
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
Yes, this is my dilemma. I think we could print more
informative message, but I am not sure.
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.
What I proposed only brings in line those systems and makes
them able to continue after hitting a permanent breakpoint
(so on systems that normally do not need adjustment, I added
advancing over the hardcoded breakpoint).