Re: [PATCH 2/2 ] PowerPC: fix for gdb.reverse/finish-precsave.exp and gdb.reverse/finish-reverse.exp

[Simon Marchi <simark@simark.ca>]

On 3/28/23 11:17, Carl Love wrote:
> Simon:
> 
> On Mon, 2023-03-27 at 21:19 -0400, Simon Marchi wrote:
>> To confirm the theory, I added a:
>>
>>    gdb_test "set range-stepping off"
>>
>> somewhere near the beginning of your test, and it makes the test pass
>> with native-gdbserver.
>>
>> If we want recording to work the same with process targets using
>> range-stepping and those that don't, maybe GDB should avoid using
>> range-stepping when the record-full target is in effect?
> 
> We could just update the test to include gdb_test "set range-stepping
> off" with a brief explanation of the issue. This would have a minimal
> impact on performance of this test and no performance degradation for
> any other tests.  It sounds like this would fix the issue for just this
> test. 
> 
> It sounds like disabling range-stepping when record-full is enabled
> would be the more general fix for the issue.  Not sure if there are
> other tests where this issue occurs.  Doing the more general fix would
> probably have some performance impact on the other tests that need to
> use record-full. I can't really say how much of an impact it would be.

It depends on what the goal is.  In general, we try to minimize the
differences in behavior when debugging native vs debugging remote.  So,
if we say that it's a bug that the record-full target doesn't see all
the intermediary steps, then putting "set range-stepping off" in that
test would just be papering over the bug.  I think the correct thing to
do would be to fix GDB.  And yes there will be a performance impact when
using remote debugging + record-full, but if that's what's needed to get
correct behavior...

Some ideas to implement this:

 - Add a target method supports_range_stepping, record-full would
   implement it and return false.  The default would be true.
 - record-full's resume method could clean the resumed thread's
   may_range_step flag.

I'm open to other ideas.  Note that we don't want to disable range
stepping for other record implementations (only btrace, currently), I
don't think that one is affected by the problem (the hardware should
record all intermediary steps in any case).

Simon