From: Pedro Alves <palves@redhat.com>
To: Antoine Tremblay <antoine.tremblay@ericsson.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH 2/2] Enable range stepping for ARM on GDBServer
Date: Wed, 31 Aug 2016 18:39:00 -0000 [thread overview]
Message-ID: <3fdb7193-60c7-49c9-ccf5-bc040aa157ea@redhat.com> (raw)
In-Reply-To: <wwokwpiwyfct.fsf@ericsson.com>
On 08/31/2016 07:15 PM, Antoine Tremblay wrote:
>
> Pedro Alves writes:
>
>> On 08/31/2016 06:14 PM, Antoine Tremblay wrote:
>>> This patch enables range stepping to be done in GDBServer with an ARM
>>> target.
>>>
>>> There is one problem however with the gdb.threads/non-stop-fair-events.exp
>>> test.
>>>
>>> Since single stepping is done in software and that displaced stepping is
>>> not supported, threads end up hitting each others breakpoints and the main
>>> thread can't make any progress passed a number of threads on my system.
>>>
>>> Thus we get:
>>> FAIL: gdb.threads/non-stop-fair-events.exp: signal_thread=5: thread 1
>>> broke out of loop (timeout)
>>>
>>> Note that even letting it go an hour doesn't help so bumping the timeout
>>> is out of the question.
>>>
>>> I'm not sure what to do about this one ? kfail ? ideas ?
>>
>> Hmm, this is exactly the sort of problem the test is meant to
>> catch, and the reason we do event thread randomization:
>>
>> # Test that GDB in non-stop mode gives roughly equal priority to
>> # events of all threads.
>>
>> Why does it work without range stepping, but not with?
>>
>
> If I recall correctly GDBServer will report each stepi to GDB
> without range stepping but will continue in gdbserver when range
> stepping is on, thus the run control is different.
>
> And that GDBServer's run control is not as fair as GDB's for such
> situations.
>
> Maybe it could be made to work, I remember trying a few things but after
> spending quite some time on it I could not wrap my head around it. Thus
> my call for ideas here.
It's between hard and impossible to give out ideas without some sort
of high level analysis of the typical loop of events gdbserver is getting
stuck in, causing the main thread to never be given a chance to
make progress.
It sounds like gdbserver's event starvation avoidance isn't really
working on sss targets with range stepping enabled. E.g., are we
doing the randomization too late?
Thanks,
Pedro Alves
next prev parent reply other threads:[~2016-08-31 18:39 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-31 17:14 [PATCH 1/2] Fix lwp_suspend/unsuspend imbalance in linux_wait_1 Antoine Tremblay
2016-08-31 17:14 ` [PATCH 2/2] Enable range stepping for ARM on GDBServer Antoine Tremblay
2016-08-31 17:50 ` Pedro Alves
2016-08-31 18:15 ` Antoine Tremblay
2016-08-31 18:39 ` Pedro Alves [this message]
2016-08-31 19:14 ` Antoine Tremblay
2016-09-01 13:37 ` Pedro Alves
2016-09-01 15:21 ` Antoine Tremblay
2016-09-01 15:59 ` Pedro Alves
2016-09-01 16:44 ` Yao Qi
2016-09-01 17:02 ` Pedro Alves
2016-09-01 17:06 ` Antoine Tremblay
2016-09-01 16:46 ` Antoine Tremblay
2016-09-18 19:58 ` Yao Qi
2016-08-31 17:40 ` [PATCH 1/2] Fix lwp_suspend/unsuspend imbalance in linux_wait_1 Pedro Alves
2016-08-31 17:50 ` Antoine Tremblay
2016-08-31 17:52 ` Pedro Alves
2016-08-31 18:25 ` Antoine Tremblay
2016-08-31 19:16 ` Antoine Tremblay
2016-09-01 13:09 ` Pedro Alves
2016-09-01 15:12 ` Antoine Tremblay
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3fdb7193-60c7-49c9-ccf5-bc040aa157ea@redhat.com \
--to=palves@redhat.com \
--cc=antoine.tremblay@ericsson.com \
--cc=gdb-patches@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox