Re: arm remote step using software breakpoints doesn't finish the step

[Simon Marchi <simon.marchi@polymtl.ca>]

On 2018-11-05 19:24, Bill Morgan wrote:
> On Mon, Nov 5, 2018 at 11:42 AM Bill Morgan 
> <arthurwilliammorgan@gmail.com>
> wrote:
> 
>> For some reason GDB is setting breakpoints in an order that is causing 
>> a
>> step to never finish.
>> 
>> It sets a breakpoint at 0x22637fd0, then that breakpoint is hit, then 
>> sets
>> one at 0x22637fd4, then that one is hit, then it puts one back at
>> 0x22637fd0 again and the remote code runs until it loops back into 
>> this
>> function again and fd0 is hit again, then sets bp at 0x22637fd4 again,
>> etc., so the result is that the step never finishes.
>> 
>> I'm wondering why it didn't set one at fd8.
>> 
>> Any ideas?
>> 
> 
> I found an issue in my remote stub. I had multiple threads in the 
> address
> space with the breakpoint.
> 
> Thread 0x1f was current, but 0x1e was resuming first and hitting the
> stepping breakpoint, so GDB kept trying to get 0x1f to hit the 
> breakpoint
> for the step.
> 
> I changed to always resume the current thread first so it has a chance 
> to
> hit the stepping breakpoint.

Hi Bill,

Good to know you managed to solve it.  You can always look at how 
gdbserver does to get inspiration.  I know that in some cases, it 
randomizes the order in which it processes events to avoid starving 
threads like that.

Simon