This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH v2 00/17] Fast tracepoint support for ARMv7
- From: Antoine Tremblay <antoine dot tremblay at ericsson dot com>
- To: Pedro Alves <palves at redhat dot com>
- Cc: Antoine Tremblay <antoine dot tremblay at ericsson dot com>, <gdb-patches at sourceware dot org>
- Date: Wed, 29 Jun 2016 15:15:37 -0400
- Subject: Re: [PATCH v2 00/17] Fast tracepoint support for ARMv7
- Authentication-results: sourceware.org; auth=none
- References: <1465476975-25062-1-git-send-email-antoine dot tremblay at ericsson dot com> <wwoky45o5ccf dot fsf at ericsson dot com> <0d896cd9-f857-db41-fdb1-2ebde0eeeb01 at redhat dot 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