From patchwork Fri Dec 28 14:13:28 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Philippe Waroquiers X-Patchwork-Id: 30894 Received: (qmail 117547 invoked by alias); 28 Dec 2018 14:13:38 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 117463 invoked by uid 89); 28 Dec 2018 14:13:37 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-27.6 required=5.0 tests=BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, RCVD_IN_DNSWL_LOW, SPF_PASS autolearn=ham version=3.3.2 spammy=lose, completed, similarly, ao X-HELO: mailsec109.isp.belgacom.be Received: from mailsec109.isp.belgacom.be (HELO mailsec109.isp.belgacom.be) (195.238.20.105) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 28 Dec 2018 14:13:31 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=skynet.be; i=@skynet.be; q=dns/txt; s=securemail; t=1546006412; x=1577542412; h=message-id:subject:from:to:date:in-reply-to:references: mime-version; bh=+GnYP5WUTk9CI1bKfKGzN8h9qY82d/OEHbox60fS4LI=; b=frx18dccPH1J8K9QtjAOS96YUsfLhcH1NMeh8rVQkUhAebrJ1UCC5xJt fpIFFimg/Ba6aIcdp0AKXLWm2O9H+g==; Received: from 184.205-67-87.adsl-dyn.isp.belgacom.be (HELO md) ([87.67.205.184]) by relay.skynet.be with ESMTP/TLS/AES256-GCM-SHA384; 28 Dec 2018 15:13:29 +0100 Message-ID: <1546006408.31031.19.camel@skynet.be> Subject: Re: [RFA] Add FORCE_LOCAL_GDB_QUIT_WAIT testsuite parameter. From: Philippe Waroquiers To: Pedro Alves , gdb-patches@sourceware.org Date: Fri, 28 Dec 2018 15:13:28 +0100 In-Reply-To: <9a290725-4ea4-ab4f-257f-2b8528e49502@redhat.com> References: <20181202234622.3119-1-philippe.waroquiers@skynet.be> <9a290725-4ea4-ab4f-257f-2b8528e49502@redhat.com> Mime-Version: 1.0 X-IsSubscribed: yes On Mon, 2018-12-03 at 12:39 +0000, Pedro Alves wrote: > On 12/02/2018 11:46 PM, Philippe Waroquiers wrote: > > This patch helps to run GDB testsuite under valgrind, by ensuring > > that the valgrind output completely goes into the gdb.log file > > (approach suggested by Pedro on irc). > > I'd first prefer to see about making this unconditional. > Does the explicit "quit" slow down native non-valgrind testing > noticeably, for example? Always doing the "quit" would help > catch bugs around GDB crashing on termination -- IIRC, I've fixed > at least a bug like that that I only noticed happened because > I found some rogue gdb core dumps in the testsuite dir. Find attached the current state of implementing a 'clean quit' of GDB at the end of a test. As it is now, it is not suitable to be activated unconditionally; but maybe the patch can be further improved. The difference in timing is significant: time make check RUNTESTFLAGS="GDB=$PWD/gdb" FORCE_PARALLEL="1" -j1 real 24m59.404s user 14m1.620s sys 2m30.536s time make check RUNTESTFLAGS="GDB=$PWD/gdb FORCE_LOCAL_GDB_QUIT_WAIT=1" FORCE_PARALLEL="1" -j1 real 47m3.698s user 10m39.088s sys 1m49.892s A few observations: * unclear why, but the FORCE uses less user and less sys cpu. * a very significant part of the real time diff is because the FORCE QUIT WAIT encounters times out for some tests, instead of doing a clean quit. I have not found a proper way to have both a clean quit without timeout, and not lose the valgrind output. The tests that have some timeouts are:  gdb.base/dprintf-detach.exp   gdb.base/jit.exp   gdb.base/pie-fork.exp   gdb.base/watchpoint-hw-attach.exp   gdb.mi/mi-break.exp   gdb.mi/mi-exec-run.exp   gdb.mi/mi-watch.exp   gdb.mi/new-ui-mi-sync.exp   gdb.mi/user-selected-context-sync.exp   gdb.server/abspath.exp   gdb.server/connect-stopped-target.exp   gdb.server/connect-without-multi-process.exp   gdb.server/file-transfer.exp   gdb.server/no-thread-db.exp   gdb.server/run-without-local-binary.exp   gdb.server/server-exec-info.exp   gdb.server/server-mon.exp   gdb.server/server-run.exp   gdb.server/solib-list.exp   gdb.server/stop-reply-no-thread.exp   gdb.server/wrapper.exp   gdb.threads/process-dies-while-handling-bp.exp The worst test is dprintf-detach, which adds 6 minutes of timeout. * even with the below patch, the valgrind output is incomplete for a few tests. As far as I can see, the lost output is mostly due to time outs. I have to admit that I am a little bit lost in the mysteries of dejagnu/expect. Whatever I am trying to change in the 'clean quit' logic, it either increases the nr of timeouts, or loses some valgrind output, or causes 'channel exp9 not open' errors. So, some advice about how to improve the logic (for both the normal and the mi 'clean quit' logic) would be welcome. Thanks Philippe. From f2ec452344d49108f3769cb8096806fa7c2d17ee Mon Sep 17 00:00:00 2001 From: Philippe Waroquiers Date: Thu, 27 Dec 2018 00:14:36 +0100 Subject: [PATCH 2/2] Implement FORCE_LOCAL_GDB_QUIT_WAIT in mi mode Change mi_gdb_exit similarly to gdb_exit. --- gdb/testsuite/lib/mi-support.exp | 60 +++++++++++++++++++++++++++++++- 1 file changed, 59 insertions(+), 1 deletion(-) diff --git a/gdb/testsuite/lib/mi-support.exp b/gdb/testsuite/lib/mi-support.exp index 235d03e902..8b02134675 100644 --- a/gdb/testsuite/lib/mi-support.exp +++ b/gdb/testsuite/lib/mi-support.exp @@ -55,6 +55,8 @@ proc mi_gdb_exit {} { proc mi_uncatched_gdb_exit {} { global GDB global INTERNAL_GDBFLAGS GDBFLAGS + global FORCE_LOCAL_GDB_QUIT_WAIT + global async global verbose global gdb_spawn_id gdb_main_spawn_id global mi_spawn_id inferior_spawn_id @@ -91,7 +93,63 @@ proc mi_uncatched_gdb_exit {} { } if ![is_remote host] { - remote_close host + # The logic here should be similar to gdb.exp (default_gdb_exit). + # See comments/explanations in gdb.exp. + + if { [info exists FORCE_LOCAL_GDB_QUIT_WAIT] } { + + # # Send the interrupt request. + # if { $async } { + # mi_gdb_test "888-exec-interrupt" "888\\^done" "interrupt" + # } else { + # send_gdb "\003" + # } + # mi_expect_interrupt + # ??? no idea how to properly interrupt in mi mode. + # ??? and should we interrupt in mi mode ? + + # Some mi tests are failing with time out, such as as mi-watch.exp, + # with: +# (gdb) +# PASS: gdb.mi/mi-watch.exp: mi-mode=separate: wp-type=hw: watchpoint trigger +# 999-gdb-exit +# 999^exit +# =thread-exited,id="1",group-id="i1" +# =thread-group-exited,id="i1" +# FAIL: gdb.mi/mi-watch.exp: mi-mode=separate: wp-type=hw: mi quit timeout +# Executing on host: kill -TERM 0 (timeout = 300) +# spawn -ignore SIGHUP kill -TERM 0 + # and I cannot see any difference with a succesful test, + # such as mi-return.exp: +# PASS: gdb.mi/mi-eval.exp: eval A + 3 +# 999-gdb-exit +# 999^exit +# =thread-exited,id="1",group-id="i1" +# =thread-group-exited,id="i1" +# testcase /bd/home/philippe/gdb/git/build_obvious/gdb/testsuite/../../../obvious/gdb/testsuite/gdb.mi/mi-eval.exp completed in 0 seconds + + send_gdb "999-gdb-exit\n" + gdb_expect 30 { + -re "y or n.*" { + send_gdb "y\n" + exp_continue + } + -re "Undefined command.*$gdb_prompt $" { + send_gdb "quit\n" + exp_continue + } + eof { } + timeout { + fail "mi force quit timeout" + set gdb_pid [spawn_id_get_pid $mi_spawn_id] + remote_exec host "kill -TERM $gdb_pid" + } + -re "DOSEXIT code" { } + } + # wait -i $gdb_spawn_id + } else { + remote_close host + } } unset gdb_spawn_id unset gdb_main_spawn_id -- 2.19.2