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

[Pedro Alves <palves@redhat.com>]

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?

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

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

> 
> 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... :-/

Thanks,
Pedro Alves