This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC][PATCH 09/15] gdb: Add relocate instruction helpers

On 15-11-23 06:00 AM, Yao Qi wrote:
> Simon Marchi <> 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

> 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?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]