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

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

Yao Qi writes:

> Antoine Tremblay <antoine.tremblay@ericsson.com> writes:
>
>>   From what I can tell issue 1) is about done ?
>>
>
> There are still some things we need to do before arm tracepoint support,
> and I am working on them,
>
>  - really exercise the software single step in gdbserver,
>    1. software single step over instruction branch to itself.  [DONE]
>    2. force gdb to use vCont;s for gdbserver using software single step,
>    IOW, let gdbserver handle single step requested by gdb,
>    3. turn range stepping on on arm linux,
>
>    I have some patches in my tree.  After these steps, we are confident
>    that software single step in gdbserver is reliable.

OK. Thanks for the update.

Is your tree public somewhere btw ? As we're (Simon and I) almost done
with the fast tracepoints if we can help with this (2. 3.) we would be
glad to.

>
>>   On my end we have fast tracepoints for arm almost ready with JIT
>>   conditions and pc relative instructions relocation.
>>
>>   I would like to post that in the next few weeks, but it would be
>>   better if the normal tracepoints were in before that.
>>
>>   Is it a good time to review these patches now?
>
>  - handle unavailable memory/register in frame unwinding in target
>    independent part, so that we don't have to worry about the
>    unavailable memory in arm backend.
>    I am writing a prototype according to Pedro's thoughts,
>    https://sourceware.org/ml/gdb-patches/2016-02/msg00778.html
>    but it is blocked by a patch related PR 19947,
>    https://sourceware.org/ml/gdb-patches/2016-04/msg00429.html
>    we need an approach to test each unwinder, the discussion is still
>    ongoing.
>

Thanks for working on that one!

Note however that this only affects the tracing of pseudo registers
iirc, maybe we can live without this at first and add it as an
improvement.

Moreover, the required code changes to fix this issue have
no impact on the tracepoint patches afaik, so I don't see it as a hard
prerequisite for tracepoints.

> I won't review arm tracepoint patches until all of them above are
> fixed.

I will still send the fast tracepoints patches when they are ready as
the code is quite independant from these issues in the hope that we can
start the review process asap.

Regards,
Antoine