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 08:59:45 +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>
Antoine Tremblay <firstname.lastname@example.org> 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.
> 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
I won't review arm tracepoint patches until all of them above are