arm remote step using software breakpoints doesn't finish the step
Simon Marchi
simon.marchi@polymtl.ca
Wed Nov 14 22:35:00 GMT 2018
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
More information about the Gdb
mailing list