This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFC][PATCH 09/15] gdb: Add relocate instruction helpers
- From: Simon Marchi <simon dot marchi at ericsson dot com>
- To: Yao Qi <qiyaoltc at gmail dot com>
- Cc: <henrik dot wallin at windriver dot com>, <gdb-patches at sourceware dot org>, Antoine Tremblay <antoine dot tremblay at ericsson dot com>
- Date: Tue, 24 Nov 2015 11:29:40 -0500
- Subject: Re: [RFC][PATCH 09/15] gdb: Add relocate instruction helpers
- Authentication-results: sourceware.org; auth=none
- References: <cover dot 1444820235 dot git dot henrik dot wallin at windriver dot com> <cover dot 1444820235 dot git dot henrik dot wallin at windriver dot com> <b3dfc6c9e6fdba064a0925c137723e63d3103362 dot 1444820235 dot git dot henrik dot wallin at windriver dot com> <86mvv4zhfj dot fsf at gmail dot com> <564F6131 dot 8030805 at ericsson dot com> <86d1v1yo8v dot fsf at gmail dot com>
On 15-11-23 06:00 AM, Yao Qi wrote:
> Simon Marchi <simon.marchi@ericsson.com> writes:
>
>> It seems like the code that Henrik adds in this patch (for relocating an
>> instruction) is very similar to the code currently in arm-tdep.c for
>> displaced stepping. I think we can extract it and place it in arch/,
>> then use it both for displaced stepping and fast tracepoints. That's
>> what aarch64 does currently, is that right? Do you think it's the
>> right way to go for arm as well?
>
> Yes, I think the instruction decoding part in arm for instruction
> relocation (for both fast tracepoint and displaced stepping) can be
> shared. The possibility of code sharing was considered at the beginning
> of aarch64 work. However, this possibility wasn't considered, AFICS,
> when the arm displaced stepping was added, so I am afraid we need to
> refactor, if not rewrite, the existing arm displaced stepping code a lot
> for the purpose of sharing code. It must take much effort.
Ok, but if that's what it takes to get fast tracepoint support on ARM, we will
consider it. It's certainly better than having a parallel implementation of
instruction decoding/relocation gdbserver-side.
> On the other hand, GDBserver can't move threads out of jump pad without
> hardware single step, which is a showstopper to ARM linux fast
> tracepoint support.
Ok, I see why that is important. However, why is hardware single step
necessary? With software single-step support added into gdbserver (thanks to
Antoine), isn't it possible to single step a thread out of the jump pad using
that?
> In short, it is right to share code, but we need to figure out how to
> move threads out of jump pad on ARM linux first. Secondly, rewrite arm
> displaced stepping code, and share decoding part with fast tracepoint
> instruction relocation. Unfortunately, the first one is still an open
> question to me.
If this problem can't be fixed directly, Antoine and I thought that we could
still have fast tracepoints support, but with known issues and some limitations,
such as not being able to instrument signal handlers, only allowing one tstart
for the life of the process (to avoid problems mentioned in stabilize_threads).
Could that be a good plan B?
Simon