[RFC] stepping over permanent breakpoint
Aleksandar Ristovski
aristovski@qnx.com
Mon Mar 16 19:04:00 GMT 2009
Mark Kettenis wrote:
>> 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.
Except on QNX gdb will not be able to continue or step over
that instruction.
>
>> 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.
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).
More information about the Gdb
mailing list