RE: [PATCH 13/17] btrace: non-stop

["Metzger, Markus T" <markus.t.metzger@intel.com>]

> -----Original Message-----
> From: Pedro Alves [mailto:palves@redhat.com]
> Sent: Thursday, September 10, 2015 1:33 PM
> To: Metzger, Markus T
> Cc: gdb-patches@sourceware.org
> Subject: Re: [PATCH 13/17] btrace: non-stop
> 
> On 09/10/2015 12:19 PM, Metzger, Markus T wrote:
> >> -----Original Message-----
> >> From: Pedro Alves [mailto:palves@redhat.com]
> >> Sent: Thursday, September 10, 2015 1:05 PM
> >> To: Metzger, Markus T
> >> Cc: gdb-patches@sourceware.org
> >> Subject: Re: [PATCH 13/17] btrace: non-stop
> >>
> >> On 09/10/2015 08:47 AM, Metzger, Markus T wrote:
> >>
> >>> That seems to be the case.  I'm still getting the error I'm checking for
> before
> >>> the prompt, though, and my test will run into a timeout.
> >>>
> >>> 	thread apply all reverse-stepi 4 &
> >>>
> >>> 	Thread 2 (Thread 0x7ffff74fb700 (LWP 70895)):
> >>>
> >>> 	Thread 1 (Thread 0x7ffff7fcc740 (LWP 70891)):
> >>> 	Cannot execute this command while the selected thread is running.
> >>> 	(gdb) PASS: gdb.btrace/non-stop.exp: reverse-step: all: thread apply
> >> all reverse-stepi 4: prompt
> >>> 	0x0000000000400671      28        for (; i < 10; ++i) global += i; /* loop */
> >>> 	PASS: gdb.btrace/non-stop.exp: reverse-step: all: thread apply all
> >> reverse-stepi 4: thread 0
> >>> 	FAIL: gdb.btrace/non-stop.exp: reverse-step: all: thread apply all
> >> reverse-stepi 4: thread 1 (timeout)
> >>>
> >>> A failing run might take a bit longer, but that should be it.
> >>
> >> Odd.  I'm running the test now for over 20 minutes, and it doesn't ever
> fail.
> >> Before I ran it against gdbserver for 10 minutes, never failed.
> >> This is with an i7-2620M; I hacked linux-btrace.c:intel_supports_bts to
> >> enable btrace.
> >
> > I reverted one of the patches to trigger the error.  I wanted to see if
> > the test catches it.  The full series should run without error, of course.
> >
> > This was meant to demonstrate that the error message precedes the
> > prompt.
> 
> Ah, I had totally misunderstood it!  I thought you were saying that a
> failing run took a bit long to trigger, so I left it running for a
> while.   In fact, I still had it running.  :-)

I meant that when a test fails, we are now waiting for the timeout.
Before, we caught the error message.  So running the test might take
longer if there are fails.

I forgot to mention that you need to revert one of the preceding
patches to trigger a fail;-)

Regards,
Markus.

Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Managing Directors: Christin Eisenschmid, Prof. Dr. Hermann Eul
Chairperson of the Supervisory Board: Tiffany Doon Silva
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928