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

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

Pedro Alves writes:

> On 06/29/2016 02:55 PM, Antoine Tremblay wrote:
>
>>> 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.
>
> I follows that url now, and I didn't see where it's mentioned
> that the issue is present with x86 as well?  It talks about
> single-step breakpoints, which x86 doesn't use?
>
Yes the threading is a bit strange, the proper url for x86 reference is
: https://sourceware.org/ml/gdb-patches/2016-02/msg00128.html

> IIRC, Yao's software single-step series fixes several bugs that 
> manifest in suspend count assertions failing.  Are you working on top
> of that?
>

I was testing on x86...

>> 
>> 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.
>
> If you put a breakpoint inside gdb_collect or one of its callees,
> then gdbserver is supposed to not try to move threads out of the
> jump pads.  This is to allow debugging the fast tracepoint machinery
> itself.
>

Yes indeed that's what I discovered.. thus my flawed test.

>> 
>> 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 ?
>
> I think I remember doing basically what you did -- run a tight
> loop that is constantly collecting a fast tracepoint, and then send
> the inferior a signal.  Then I'd do "bt" and look for a "gdb_collect"
> frame.  If one was shown, there was a bug.  I remember trying and
> observing all the nasty situations described on top
> of linux_stabilize_threads, but I don't remember ever converting them
> to proper testcases... :-/
>

OK, I guess I have to find a way to interrupt it, in my case using a
circular buffer, trying c& and interrupt as no effect or C-c with
continue...

I'll try a less tight loop and check that's it's in the traced code but
not in the usleep...

In the meantime it made me test arm fast tracepoints with a thight loop
like that and it crashes the inferiror when the agent buffer is full :(

I'll fix that 1st..

Thanks,
Antoine