This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [rfc, spu] Don't call set_gdbarch_cannot_step_breakpoint in spu_gdbarch_init
- From: Pedro Alves <palves at redhat dot com>
- To: Peter Schauer <peterschauer at gmx dot net>
- Cc: Yao Qi <qiyaoltc at gmail dot com>, gdb-patches at sourceware dot org, Ulrich Weigand <uweigand at de dot ibm dot com>
- Date: Thu, 02 Apr 2015 10:38:41 +0100
- Subject: Re: [rfc, spu] Don't call set_gdbarch_cannot_step_breakpoint in spu_gdbarch_init
- Authentication-results: sourceware.org; auth=none
- References: <201504020909 dot t3299MbW015585 at licht dot localdomain>
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