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:
>
>> 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.
>
> This tree https://github.com/qiyao/gdb/tree/arm-sw-single-step-2
> includes two commits that
>  1) forces GDB use vCont;s with arm-linux gdbserver,
>  2) enable range stepping on arm-linux,
>
> they'll cause some test failures, and you can start from them.  I am not
> sure what is the best fix could be so far, so I don't publish my fixes.
> My patches might be completely wrong.
>

That's completly fine, thanks for sharing your work in progress, it
should give us a good start.

> I don't mind if you guys jump in the muddy puddles together with me.
>

Thanks, we'll do our best.

>>
>>>
>>>>   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 don't think so.  If that is done, unwinders in each target don't have
> to worry about the unavailable memory/register, your patch 1/4 in this
> series is no longer needed.

Yes the 1/4 patch is no longer needed, that's a given we can abandon it,
but I don't see it impacting anything else code wise.

We can try to coordonate a bit too if you want since for us the unwinder
patch seems harder than the single step fixing, if you want to focus on
the unwinder, we will focus on the vCont/range and hopefully we'll make faster
progress ?

Thanks,
Antoine