From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 76872 invoked by alias); 23 Aug 2016 14:47:51 -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 76853 invoked by uid 89); 23 Aug 2016 14:47:51 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=beneath, 2289, sig, hw X-HELO: mail-pa0-f65.google.com Received: from mail-pa0-f65.google.com (HELO mail-pa0-f65.google.com) (209.85.220.65) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 23 Aug 2016 14:47:46 +0000 Received: by mail-pa0-f65.google.com with SMTP id vy10so10046061pac.0 for ; Tue, 23 Aug 2016 07:47:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:message-id:user-agent :mime-version:content-transfer-encoding; bh=tf6TeDbzNjLR4bTkdws7w5ctp+YN+EITd33TRXhhtrE=; b=f/UejyBfBAE0nF3k798xkChCCKCGwi1oK+H7Jp4xt5QEu+fUi3Qm9ucW3j9j4BYPHM pDfbUB9AZhM+O7ZH48+FtrdeKYWNQyjizZOW0JtYCEae4/mLlEsDObT0miN8CGIMzvXF WtB7N8p3EbY2s+xnSDw+q2IrS2Kmfo3PH6I3xuaqXKLuCV6U/aPCf48BRDA+hqiaGkTI HucYxsP+7mXeegbcKnyL2HdvIaQFz6GPgqyD3tmUijGGX5HNrbd8RDJ4KARwGDapfVrj WvguBZuyfGEnQ6zhAj1voWDY9ZR576SCUOJtAsjqTpGWMthiPt2ehfMVOyrkuGNvF9CH GxwQ== X-Gm-Message-State: AEkoouslnvzYuciRs5ntzw2XlOYD4HB6rgEd2BG2yZenKZymT5BkpqTsYjgDJHdWxX8H6w== X-Received: by 10.67.7.229 with SMTP id df5mr53060894pad.6.1471963664273; Tue, 23 Aug 2016 07:47:44 -0700 (PDT) Received: from E107787-LIN (gcc115.osuosl.org. [140.211.9.73]) by smtp.gmail.com with ESMTPSA id o80sm6431114pfa.67.2016.08.23.07.47.41 for (version=TLS1_2 cipher=AES128-SHA bits=128/128); Tue, 23 Aug 2016 07:47:43 -0700 (PDT) From: Yao Qi To: gdb-patches@sourceware.org Subject: Run process-dies-while-detaching.exp with SW watchpoint Date: Tue, 23 Aug 2016 14:47:00 -0000 Message-ID: <86zio3bkzb.fsf@gmail.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: 2016-08/txt/msg00229.txt.bz2 Hi, I see the following fail when I run tests on some ARM board without HW watchpoint support, (gdb) watch globalvar^M Watchpoint 2: globalvar^M (gdb) FAIL: gdb.threads/process-dies-while-detaching.exp: single-process: d= etach: watchpoint: watch globalvar I think we should run test_detach_watch with both HW watchpoint and SW watchpoint. I modified it, as the patch shown below, but the test_detach_watch with SW watchpoint causes some test fails even on x86_64, Thread 12 "process-dies-wh" hit Temporary breakpoint 3, 0x00002aaaaafaf2d0 = in _exit () from /lib/x86_64-linux-gnu/libc.so.6^M (gdb) PASS: gdb.threads/process-dies-while-detaching.exp: single-process: c= ontinue: watchpoint hw=3D0: continue to breakpoint: _exit continue^M Continuing.^M Cannot find user-level thread for LWP 2363: generic error^M (gdb) FAIL: gdb.threads/process-dies-while-detaching.exp: single-process: c= ontinue: watchpoint hw=3D0: continue When the error is thrown, the stack backtrace is=20 (gdb) bt 10 #0 thread_from_lwp (ptid=3D...) at /home/yao/SourceCode/gnu/gdb/git/gdb/li= nux-thread-db.c:356 #1 0x0000000000460fb4 in thread_db_wait (ops=3D, ptid=3D...= , ourstatus=3D0x7fff702c0510, options=3D1) at /home/yao/SourceCode/gnu/gdb/git/gdb/linux-thread-db.c:1146 #2 0x00000000005b69cd in delegate_wait (self=3D, arg1=3D...= , arg2=3D, arg3=3D) at /home/yao/SourceCode/gnu/gdb/git/gdb/target-delegates.c:116 #3 0x00000000005c5bb4 in target_wait (ptid=3D..., status=3Dstatus@entry=3D= 0x7fff702c0510, options=3Doptions@entry=3D1) at /home/yao/SourceCode/gnu/gdb/git/gdb/target.c:2289 #4 0x0000000000578269 in do_target_wait (ptid=3D..., status=3Dstatus@entry= =3D0x7fff702c0510, options=3D1) at /home/yao/SourceCode/gnu/gdb/git/gdb/inf= run.c:3641 #5 0x0000000000583a1b in fetch_inferior_event (client_data=3D) at /home/yao/SourceCode/gnu/gdb/git/gdb/infrun.c:3952 #6 0x0000000000598cd5 in gdb_wait_for_event (block=3Dblock@entry=3D0) at /= home/yao/SourceCode/gnu/gdb/git/gdb/event-loop.c:859 #7 0x0000000000598ee5 in gdb_do_one_event () at /home/yao/SourceCode/gnu/g= db/git/gdb/event-loop.c:322 #8 0x0000000000598f55 in start_event_loop () at /home/yao/SourceCode/gnu/g= db/git/gdb/event-loop.c:371 #9 0x0000000000592d18 in captured_command_loop (data=3Ddata@entry=3D0x0) a= t /home/yao/SourceCode/gnu/gdb/git/gdb/main.c:324 and the "ourstatus" got from beneath->to_wait is (gdb) p *ourstatus $1 =3D {kind =3D TARGET_WAITKIND_STOPPED, value =3D {integer =3D 5, sig =3D= GDB_SIGNAL_TRAP, related_pid =3D {pid =3D 5, lwp =3D 0, tid =3D 0},=20 execd_pathname =3D 0x5 , sy= scall_number =3D 5}} looks linux-nat target thinks the thread is stopped, but thread-db can't find the thread. Is it a known problem (in gdb or glibc)? --=20 Yao (=E9=BD=90=E5=B0=A7) diff --git a/gdb/testsuite/gdb.threads/process-dies-while-detaching.exp b/g= db/testsuite/gdb.threads/process-dies-while-detaching.exp index 52dc8dd..39cba31 100644 --- a/gdb/testsuite/gdb.threads/process-dies-while-detaching.exp +++ b/gdb/testsuite/gdb.threads/process-dies-while-detaching.exp @@ -209,10 +209,12 @@ proc test_detach {multi_process cmd} { } } =20 -# Same as test_detach, except set a watchpoint before detaching. +# Same as test_detach, except set a watchpoint before detaching. HW +# is true if hardware watchpoint is used. =20 -proc test_detach_watch {multi_process cmd} { - with_test_prefix "watchpoint" { +proc test_detach_watch {hw multi_process cmd} { + + with_test_prefix "watchpoint hw=3D$hw" { global binfile decimal =20 clean_restart ${binfile} @@ -230,15 +232,25 @@ proc test_detach_watch {multi_process cmd} { gdb_continue_to_breakpoint "child_function" ".*" } =20 + if { ! $hw } { + gdb_test_no_output "set can-use-hw-watchpoints 0" "" + } # Set a watchpoint in the child. - gdb_test "watch globalvar" ".* watchpoint $decimal: globalvar" + gdb_test "watch globalvar" ".*\[Ww\]atchpoint $decimal: globalvar" =20 # Continue to the _exit breakpoint. This arms the watchpoint # registers in all threads. Detaching will thus need to clear # them out, and handle the case of the thread disappearing # while doing that (on targets that need to detach from each # thread individually). - continue_to_exit_bp + if { ! $hw } { + # Software watchpoint is quite slow. + with_timeout_factor 10 { + continue_to_exit_bp + } + } else { + continue_to_exit_bp + } =20 do_detach $multi_process $cmd } @@ -313,7 +325,11 @@ proc do_test {multi_process cmd} { } =20 test_detach $multi_process $cmd - test_detach_watch $multi_process $cmd + if { ![target_info exists gdb,no_hardware_watchpoints] } { + test_detach_watch 1 $multi_process $cmd + } + test_detach_watch 0 $multi_process $cmd + test_detach_killed_outside $multi_process $cmd } =20