From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28535 invoked by alias); 17 Dec 2014 11:10:39 -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 28441 invoked by uid 89); 17 Dec 2014 11:10:38 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 17 Dec 2014 11:10:35 +0000 Received: from svr-orw-fem-05.mgc.mentorg.com ([147.34.97.43]) by relay1.mentorg.com with esmtp id 1Y1CUy-0003SA-9i from Yao_Qi@mentor.com ; Wed, 17 Dec 2014 03:10:32 -0800 Received: from GreenOnly (147.34.91.1) by svr-orw-fem-05.mgc.mentorg.com (147.34.97.43) with Microsoft SMTP Server id 14.3.181.6; Wed, 17 Dec 2014 03:10:31 -0800 From: Yao Qi To: Pedro Alves CC: Subject: Re: [PATCH 5/5] Test attaching to a program that constantly spawns short-lived threads References: <1418748834-27545-1-git-send-email-palves@redhat.com> <1418748834-27545-6-git-send-email-palves@redhat.com> Date: Wed, 17 Dec 2014 11:10:00 -0000 In-Reply-To: <1418748834-27545-6-git-send-email-palves@redhat.com> (Pedro Alves's message of "Tue, 16 Dec 2014 16:53:54 +0000") Message-ID: <87wq5qsfaf.fsf@codesourcery.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2014-12/txt/msg00474.txt.bz2 Pedro Alves writes: > +if [is_remote target] then { > + return 0 > +} We should check "![isnative] || [is_remote host] || [target_info exists use_gdb_stub]" inst= ead? > + > +standard_testfile > + > +# The test proper. See description above. > + > +proc test {} { > + global binfile > + global gdb_prompt > + global decimal > + > + clean_restart ${binfile} > + > + set testpid [spawn_wait_for_attach $binfile] > + > + set attempts 10 > + for {set attempt 1} { $attempt <=3D $attempts } { incr attempt } { > + with_test_prefix "iter $attempt" { > + set attached 0 > + set eperm 0 > + set test "attach" > + gdb_test_multiple "attach $testpid" $test { > + -re "new threads in iteration" { > + # Seen when "set debug libthread_db" is on. > + exp_continue > + } > + -re "warning: Cannot attach to lwp $decimal: Operation not permitted" { > + # On Linux, PTRACE_ATTACH sometimes fails with > + # EPERM, even though /proc/PID/status indicates > + # the thread is running. > + set eperm 1 > + exp_continue > + } > + -re "debugger service failed.*$gdb_prompt $" { > + fail $test > + } > + -re "$gdb_prompt $" { > + if {$eperm} { > + kfail "gdb/NNNN" "$test (EPERM)" Replace NNNN with a PR number? > + } else { > + pass $test > + } > + } > + -re "Attaching to program.*process $testpid.*$gdb_prompt $" { > + pass $test > + } > + } > + > + # Sleep a bit and try updating the thread list. We should > + # know about all threads already at this point. If we see > + # "New Thread" or similar being output, then "attach" is > + # failing to actually attach to all threads in the process, > + # which would be a bug. > + sleep 1 > + set saw_new 0 > + set test "info threads" > + gdb_test_multiple $test $test { > + -re "New " { > + set saw_new 1 > + exp_continue > + } > + -re "$gdb_prompt $" { > + } > + } > + > + gdb_assert !$saw_new "no new threads" Nit: I feel the test above can be simplified a little bit, gdb_test_multiple $test $test { -re "New .*$gdb_prompt $" { fail "no new threads" } -re "$gdb_prompt $" { pass "no new threads" } } --=20 Yao (=E9=BD=90=E5=B0=A7)