Re: [rfc, spu] Don't call set_gdbarch_cannot_step_breakpoint in spu_gdbarch_init

[Pedro Alves <palves@redhat.com>]

On 04/02/2015 10:09 AM, Peter Schauer wrote:
>> On 04/01/2015 09:35 PM, Peter Schauer wrote:
>>
>>> This was needed for alpha OSF/1.
>>>
>>> Back then it was the only architecture which would not ptrace step
>>> over an inserted breakpoint, causing an infinite loop while trying
>>> to single step over an inserted breakpoint.
>>
>> OOC, do you recall whether the infinite loop was that the step didn't
>> make progress, and gdb would continuously issue a single-step forever,
>> or whether the infinite loop was all in the kernel?
> 
> The step didn't make progress and GDB would have continuously issued
> a single-step forever.

OK, thanks.

> 
>>> The diff back then was
>>>
>>> + #ifdef CANNOT_STEP_BREAKPOINT
>>> +   /* If the target doesn't support stepping over a breakpoint, simply
>>> +      continue, we will then hit the breakpoint anyway.  */
>>> +   if (step && breakpoints_inserted && breakpoint_here_p (read_pc ()))
>>> +     step = 0;
>>> + #endif
>>>
>>> I do not know if GDB ever tries to ptrace step over an inserted
>>> breakpoint nowadays, sorry.
>>
>> It does in some cases when we have a signal to deliver at the
>> same time we are trying to step over a breakpoint.  Look for
>> "signal arrived while stepping over" in infrun.c.
> 
> Yeah, that was also the reason why we had to keep the breakpoint
> inserted back then.
> 
>>> Meanwhile the alpha OSF/1 port is dead anyways...
>>
>> The setting ended up done for all alpha ports today though, in:
>>
>>   alpha-tdep.c:  set_gdbarch_cannot_step_breakpoint (gdbarch, 1);
>>
>> OSF/1 is gone, but we still support Alpha GNU/Linux, which is also
>> taking that code path,. If this was OSF/1 specific, then we could
>> get rid of that too, and then get rid of gdbarch_cannot_step_breakpoint
>> completely.  Anyone have access to Alpha GNU/Linux to try that out?
> 
> If it really happens on Alpha GNU/Linux, we could request a fix from the
> kernel folks and phase out this ugly gdbarch_cannot_step_breakpoint hack
> slowly.

Yeah.  I think the hack is probably breaking the case of nested
signals while stepping over a breakpoint (gdb.base/signest.exp), as nothing
is forcing the insertion of breakpoints when the hack triggers.  If
needed, it should probably be merged with the code below for
software-step targets:

  /* Currently, our software single-step implementation leads to different
     results than hardware single-stepping in one situation: when stepping
     into delivering a signal which has an associated signal handler,
     hardware single-step will stop at the first instruction of the handler,
     while software single-step will simply skip execution of the handler.
     ...

Thanks,
Pedro Alves