Re: [RFC] stepping over permanent breakpoint

[Aleksandar Ristovski <aristovski@qnx.com>]

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).