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

[Yao Qi <qiyaoltc@gmail.com>]

On Tue, Nov 8, 2016 at 1:28 AM, Antoine Tremblay
<antoine.tremblay@ericsson.com> wrote:
>

>>
>> 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 have two boards for testing pandaboard (3.4.0-2-linaro-lt-omap)
and chromebook (4.7.2).  I got non-stop-fair-events.exp timeout
from time to time, you can get gdb.log here,
http://people.linaro.org/~yao.qi/gdb/arm-linux-tracepoint/non-stop-fair-events/

I can also see SIGILL or SIGSEGV in schedlock.exp,
http://people.linaro.org/~yao.qi/gdb/arm-linux-tracepoint/schedlock/

if I hack gdbserver/linux-low.c to disable software single step,
 static int
 can_software_single_step (void)
 {
-  return (the_low_target.get_next_pcs != NULL);
+  return 0/*(the_low_target.get_next_pcs != NULL)*/;
 }

the fails goes away.

>> This reveals something wrong in software single step in GDBserver.
>> I don't think we should bring tracepoint in until these regressions are
>> fixed.I won't work on these regressions until next pre-release.  If
>> you can reproduce them and help to fix them, that will be great.
>
> I will do my best to fix these issues asap,
>
> However I would very much like if we could still start the review
> process on the tracing.

I'll play with them, and give some review later.

-- 
Yao (齐尧)