Re: [PATCH V2 0/5] Support tracepoints for ARM linux in GDBServer

[Antoine Tremblay <antoine dot tremblay at ericsson dot com>]

Antoine Tremblay writes:

> Yao Qi writes:
>
>> On Thu, Nov 3, 2016 at 2:32 PM, Antoine Tremblay
>> <antoine.tremblay@ericsson.com> wrote:
>>>
>>> Since all the prerequisites for this series have been addressed,
>>> this is a V2 of https://sourceware.org/ml/gdb-patches/2016-01/msg00111.html
>>
>> All "hard" prerequisites are addressed, but we still want to "teach
>> unwinders to terminate gracefully in an arch-independent way".
>> https://sourceware.org/ml/gdb-patches/2016-05/msg00060.html
>> I didn't follow it up closely.  I hope we can make progress on this...
>> "Progress" here means either "it is completely wrong, let us handle
>> unavailable data in each arch unwinder one by one" or "it is
>> correct, let us remove these redundant code in each arch".
>
> Sure, I hope progress can be made on that point too.
>
>>
>> I am still testing arm-linux gdbserver without and with software
>> single step.  I still see some intermittent regressions _with_
>> software single step,
>>
>> +FAIL: gdb.threads/non-stop-fair-events.exp: signal_thread=8: thread 1
>> broke out of loop (timeout)
>> +FAIL: gdb.threads/schedlock.exp: schedlock=off: cmd=step: step to
>> increment (1) (timeout)
>>
>
> I have not seen that except when I get random SIGILLs, I'll try to run
> these more often and see if I can reproduce it.
>

I retested on my boards with RACY_ITER=100 and I can only reproduce this
issue when I get these random SIGILLs, do you have more information
about how the test ended ? (gdb.log output ? )

>> This reveals something wrong in software single step in GDBserver.

It may be another problem also, like it is with my boards...

>> I don't think we should bring tracepoint in until these regressions are
>> fixed.

Thinking more about this I can't believe we would hold back tracepoints
and fast tracepoints for an intermittent problem like that.

For the following reasons:

 - The benefit of tracepoints / fast tracepoints functionality to the
   user is significant.
 - This benefit far outweighs minor issues that could be hit.
 - I don't think it's a requirement for a feature to be absolutely
   perfect to be accepted upstream especially when there's a commitment
   to fix issues along life of the project.

Bottom line is we can fix this minor issue and the users can have
tracepoints at the same time.  If a user stumbles upon this problem it
most likely wont ruin it's day, but lack of tracepoints support is a
problem for many users.

WDYT ?