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: Mon, 7 Nov 2016 20:28:33 -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>
- Spamdiagnosticmetadata: NSPM
- Spamdiagnosticoutput: 1:99
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.
> 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.
Given that we're commited to fixing this before the next release as it
affects code that is already in.
I would not want to be in a situation where single step issues are fixed
just before the release and tracepoints have to wait for yet another release
you understand my concern ?