This is the mail archive of the
mailing list for the GDB project.
Re: [PATCH 0/4] Support tracepoints for ARM linux in GDBServer
- From: Yao Qi <qiyaoltc at gmail dot com>
- To: Antoine Tremblay <antoine dot tremblay at ericsson dot com>
- Cc: Yao Qi <qiyaoltc at gmail dot com>, <gdb-patches at sourceware dot org>
- Date: Wed, 27 Apr 2016 14:57:07 +0100
- Subject: Re: [PATCH 0/4] Support tracepoints for ARM linux in GDBServer
- Authentication-results: sourceware.org; auth=none
- References: <1452188697-23870-1-git-send-email-antoine dot tremblay at ericsson dot com> <867fjgwbsh dot fsf at gmail dot com> <wwokeg9s18z2 dot fsf at ericsson dot com> <86lh3zfpn2 dot fsf at gmail dot com> <wwokbn4v1ci0 dot fsf at ericsson dot com>
Antoine Tremblay <firstname.lastname@example.org> 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.
I don't mind if you guys jump in the muddy puddles together with me.
>>> 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,
>> but it is blocked by a patch related PR 19947,
>> we need an approach to test each unwinder, the discussion is still
> 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
> 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.