From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20878 invoked by alias); 21 Sep 2016 16:40:45 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 20866 invoked by uid 89); 21 Sep 2016 16:40:44 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-5.0 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=sleep, concepts, basket, tot X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 21 Sep 2016 16:40:43 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 545359F72D; Wed, 21 Sep 2016 16:40:42 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u8LGecNV030331; Wed, 21 Sep 2016 12:40:39 -0400 Subject: Re: [PATCH master+7.12 v2 3/3] Add test for user context selection sync To: Simon Marchi References: <20160914174548.5873-1-simon.marchi@ericsson.com> <20160914174548.5873-4-simon.marchi@ericsson.com> <3b2d8c6c3f8cfb4c008162e6f1bad226@simark.ca> Cc: Simon Marchi , gdb-patches@sourceware.org, Antoine Tremblay From: Pedro Alves Message-ID: <3daec8aa-b88a-e0a1-fe63-4574ef09fbbe@redhat.com> Date: Wed, 21 Sep 2016 16:43:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <3b2d8c6c3f8cfb4c008162e6f1bad226@simark.ca> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-09/txt/msg00259.txt.bz2 On 09/16/2016 03:01 AM, Simon Marchi wrote: > On 2016-09-14 15:31, Pedro Alves wrote: >> Hi Simon, >> >> I didn't try to understand everything in detail, but overall >> it looks very nice now. Thank you very much. A few comments below. > > Oops, while trying to rerun the full testsuite, I noticed that it leaves > "-ex \"set non-stop 1\"" in the GDBFLAGS... that's not good. You can > see it easily if you swap the order of the "all-stop" and "non-stop" > variations. Can you spot why the save_vars isn't working as intended? > When I use a temporary variable instead, it works as intended... Did you ever figure this out? >> Did you try using barriers and breakpoints? Several tests use that >> to make sure threads are past a point. > > I tried, but the issue is that depending on the scheduling, the threads > might still be in the pthread_barrier_wait function when you stop. > > Consider this pseudo-code: > > thread_function: > barrier_wait > infinite_loop # This is where I want the threads to be stopped. > > main_thread (): > initialize_barrier with n = 3 > spawn_thread (thread_function) > spawn_thread (thread_function) > barrier_wait > breakpoint > > Once the main thread hits the breakpoint, we have the assurance that the > threads have started, but we don't know where they are. They might not > have exited the barrier_wait function, or they might be in the infinite > loop. Adding a sleep before the breakpoint in the main thread is the > only way to be reasonnably sure (assuming 1 second is enough...) that > both threads will have reached the infinite loop. > > Actually, it might work by putting thread-specific breakpoints on the > single-line infinite loop, then doing two "continue". This way I think > we would be guaranteed that the two threads stop exactly at that line. > With a regular breakpoint it might not work, since a thread could hit > the breakpoint twice while the other still hasn't reached it. What I've done in the past is something very much like your breakpoints idea. Though, instead of a thread-specific breakpoint, I used a normal breakpoint + "set scheduler-locking on" to control which thread got to the breakpoint. See multiple-step-overs.exp, for example. Using a thread-specific breakpoint maybe makes that a little simpler, worth a try. >> Hmm, looks like this version of the test still runs forever. > > I don't think so, the main thread sets the quit flag which unblocks the > threads. If you run the executable you'll see it exits in ~2 seconds. Ah, OK. >> gdb_test_multiple ? > > Like this? > > set test "interrupt thread $inf.2" > > send_gdb "interrupt\n" > gdb_test_multiple "" $test { > -re "Thread.*2.*stopped" { > pass $test > } > } No need for the separate send_gdb call: set test "interrupt thread $inf.2" gdb_test_multiple "interrupt" $test { -re "Thread.*2.*stopped" { pass $test } } >>> + with_spawn_id $gdb_main_spawn_id { >>> + # TODO: it doesn't work as of now. >>> + # match_re_or_ensure_not_output "$cli_re\r\n" >>> "-thread-select, event on cli" >>> + } >> >> Is there a plan here? > > I think that will go in the same basket as the fact that any MI command > with --thread currently changes the selected thread silently (without > any =thread-selected event). Currently, --thread changes the thread tot > he desired one, then when the mi_cmd_thread_select tries to change the > thread, it thinks that it was already the current thread, so that an > event isn't necessary. This should get fixed in the next iteration, > when we split the concepts of user-selected-ptid and > internally-selected-ptid. Specifying --thread won't mess with the > user-selected-ptid, but if you do "-thread-select --thread 2 2", then > mi_cmd_thread_select will change the user-selected-ptid, generating an > event. > > It's not pretty to leave it like this in the test though. Should I > create a bug right now and kfail it? Leave it commented out but put a > better description? There's no right or wrong answer, but since you've already written the bits, I'd be inclined to file bug and kfail. Thanks, Pedro Alves