Re: [PATCH v2 00/17] Fast tracepoint support for ARMv7

[Antoine Tremblay <antoine.tremblay@ericsson.com>]

Antoine Tremblay writes:

> Hi,
>
> This is a v2 of:
> https://sourceware.org/ml/gdb-patches/2015-10/msg00195.html
>
> It needs to be applied on top of tracepoints support for ARM see:
> https://sourceware.org/ml/gdb-patches/2016-01/msg00111.html
>
> This patch enables fast tracepoints for ARM on Linux.
>
> It has been reworked by Simon Marchi and Antoine Tremblay and the
> following features have been added:
>
>   * Relocation of many PC relative instructions.
>
>   * JIT compilation of the condition expression.
>
> There are some limitations:
>
>   * The tracepoint insertion will fail if the distance from the
>     instruction to the jump pad is big.
>
>   * It is only possible to place fast tracepoints on 4-byte
>     instructions, which also limits the valid locations in Thumb mode.
>
> Known Issues:
>
> There is a possible issue while stepping out of the jump pad as discussed
> here: https://sourceware.org/ml/gdb-patches/2016-01/msg00673.html
>
> But this issue is present in x86 with hardware single stepping too. So I
> don't think it's related to this series and can be addressed separately.
> I'm still mentioning it as it may be relevant while testing software
> single stepping out of the jump pad.

About this possible known issue, after more investigation it turns out
this is because my test to try to test moving out of the jump pad is
flawed. So there's no reason to believe that the software single step to
move out of the jump pad has a problem based on that.

The fact that I would stop a thread with a breakpoint inside the
jumppad is problematic since even if I removed the breakpoint to
simulate that gdb happened to stop there while the process was
interrupted gdb still assumes with last_resume_kind that the user wants
this thread stopped and thus it fails go through the proper code
paths.

I tried testing the moving out of jump pad logic by running a while loop
with only one fast tracepoint collecting there and then interrupting it
at random but surprisingly this has some problems.

It seems the trace stops on it's own even with buffer size unlimited on
x86, I'm not sure if the trace buffer can actually be unlimited so I
tested also with circular-buffers on and this that I just can't
interrupt the process...

Would anyone have an idea on a way to test the move out of the jump pad
logic ? Pedro maybe ? Did you have a way to test it when you wrote that
code ?

Thanks,
Antoine