This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH V2 0/5] Support tracepoints for ARM linux in GDBServer
- From: Antoine Tremblay <antoine dot tremblay at ericsson dot com>
- To: Yao Qi <qiyaoltc at gmail dot com>
- Cc: Antoine Tremblay <antoine dot tremblay at ericsson dot com>, "gdb-patches at sourceware dot org" <gdb-patches at sourceware dot org>
- Date: Tue, 8 Nov 2016 10:34:21 -0500
- Subject: Re: [PATCH V2 0/5] Support tracepoints for ARM linux in GDBServer
- Authentication-results: sourceware.org; auth=none
- Authentication-results: spf=none (sender IP is ) smtp.mailfrom=antoine dot tremblay at ericsson dot com;
- References: <20161103143300.24934-1-antoine.tremblay@ericsson.com> <CAH=s-PMocQH1gJQZoGoX3PCguUm8JETVH9+8Sh8Sc-GnawqJaA@mail.gmail.com> <wwoka8dasqta.fsf@ericsson.com>
- Spamdiagnosticmetadata: NSPM
- Spamdiagnosticoutput: 1:99
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 ?