This is the mail archive of the
mailing list for the GDB project.
Re: [PATCH 2/2] Enable range stepping for ARM on GDBServer
- From: Antoine Tremblay <antoine dot tremblay at ericsson dot com>
- To: Pedro Alves <palves at redhat dot com>
- Cc: Antoine Tremblay <antoine dot tremblay at ericsson dot com>, Yao Qi <qiyaoltc at gmail dot com>, <gdb-patches at sourceware dot org>
- Date: Thu, 1 Sep 2016 12:46:23 -0400
- Subject: Re: [PATCH 2/2] Enable range stepping for ARM on GDBServer
- Authentication-results: sourceware.org; auth=none
- References: <email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com>
Pedro Alves writes:
> On 09/01/2016 04:21 PM, Antoine Tremblay wrote:
>> Pedro Alves writes:
>>> On 08/31/2016 08:14 PM, Antoine Tremblay wrote:
>>>> I'm sorry I can't be more helpful at the moment but I wanted to post
>>>> this issue before I have to leave for a while.
>>> Understood. Does enabling range stepping unblock something else?
>> It would unblock ARM tracepoints, as per Yao's requirements...
> Tracepoints make gdbserver single-step and then not report the event
> to gdb, so I do see the parallel with range-stepping. Throwing
> while-stepping into the equation would make it even more clear.
> But maybe we can paralyze? If enabling tracepoints without range
> stepping causes no known regression, but enabling range stepping with
> no tracepoints causes regressions, seems to me like we could put
> tracepoints in first, and fix whatever range stepping problems
> in parallel.
I would totally agree with that. (tracepoints do not cause any
regressions without range stepping)
> Skipping the test sounds far from ideal to me, since the test has a
> tendency of catching problems. Witness patch 1/2 in this very
> series, for example...