Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Tom de Vries <tdevries@suse.de>
To: Philippe Waroquiers <philippe.waroquiers@skynet.be>,
	Pedro Alves <palves@redhat.com>,
	gdb-patches@sourceware.org
Subject: Re: [OB PATCH][gdb/testsuite] Handle removed valgrind option --db-attach
Date: Thu, 25 Oct 2018 10:09:00 -0000	[thread overview]
Message-ID: <a1c8bbef-47a7-d120-b0b3-ce2b9b66575c@suse.de> (raw)
In-Reply-To: <1540414236.12106.12.camel@skynet.be>

[-- Attachment #1: Type: text/plain, Size: 1604 bytes --]

On 10/24/18 10:50 PM, Philippe Waroquiers wrote:
> On Wed, 2018-10-24 at 17:29 +0100, Pedro Alves wrote:
>> On 10/24/2018 12:13 PM, Tom de Vries wrote:
>>> Hi,
>>>
>>> When running valgrind-db-attach.exp with valgrind version 3.13.0, we get:
>>> ...
>>> PASS: gdb.base/valgrind-db-attach.exp: spawn valgrind
>>> valgrind: Unknown option: --db-attach=yes
>>> valgrind: Use --help for more information or consult the user manual.
>>> ERROR: Process no longer exists
>>> UNRESOLVED: gdb.base/valgrind-db-attach.exp: valgrind started
>>> ...
>>>
>>> The valgrind option --db-attach has been deprecated in version 3.10.0, and
>>> removed in version 3.11.0.
>>>
>>
>> But was it replaced with / renamed to something else equivalent,
>> or the functionality completely eliminated?
> --db-attach option functionality was removed, as it was not very
> reliable and had a bunch of limitations e.g. not supporting threads.
> 
> Instead, the gdbserver embedded in valgrind allows the user debug a process
> when valgrind reports an error.
> 
> I have put on my list of things to do to convert valgrind-attach
> test to use vgdb (but the conversion is probably not trivial).

The valgrind-db-attach.exp test-case is very similar to the
valgrind-infcall.exp test-case (using vgdb), so I gave it a try by
putting the two alongside, and doing a copy/paste/replace.

OK for trunk (perhaps with a rename to valgrind-bt.{exp,c})?

[ Or perhaps first factor out a vgdb_start/stop or some such from
valgrind-disp-step.exp and valgrind-infcall.exp, and then use those
procs in valgrind-db-attach.exp instead? ]

Thanks,
- Tom

[-- Attachment #2: 0001-gdb-testsuite-Rewrite-valgrind-db-attach.exp-to-use-vgdb.patch --]
[-- Type: text/x-patch, Size: 4694 bytes --]

[gdb/testsuite] Rewrite valgrind-db-attach.exp to use vgdb

The valgrind option --db-attach has been deprecated in version 3.10.0, and
removed in version 3.11.0, so the valgrind-db-attach.exp testcase is
unsupported starting version 3.11.0.

Rewrite the test-case to use vgdb instead (making it supported starting
version 3.7.0).

Tested on x86_64-linux with and without --target_board=native-gdbserver.

2018-10-25  Tom de Vries  <tdevries@suse.de>

	* gdb.base/valgrind-db-attach.exp: Rewrite to use vgdb.

---
 gdb/testsuite/gdb.base/valgrind-db-attach.exp | 80 ++++++++++++++++++---------
 1 file changed, 55 insertions(+), 25 deletions(-)

diff --git a/gdb/testsuite/gdb.base/valgrind-db-attach.exp b/gdb/testsuite/gdb.base/valgrind-db-attach.exp
index 3e40283a95..348f74379d 100644
--- a/gdb/testsuite/gdb.base/valgrind-db-attach.exp
+++ b/gdb/testsuite/gdb.base/valgrind-db-attach.exp
@@ -23,16 +23,8 @@ if {[build_executable $testfile.exp $testfile $srcfile {debug}] == -1} {
     return -1
 }
 
-gdb_exit
-
-# remote_spawn breaks the command on each whitespace despite possible quoting.
-# Use backslash-escaped whitespace there instead:
-
-set db_command "--db-command=$GDB $INTERNAL_GDBFLAGS $GDBFLAGS [host_info gdb_opts] %f %p"
-regsub -all " " $db_command "\\ " db_command
-
 set test "spawn valgrind"
-set cmd "valgrind --db-attach=yes $db_command $binfile"
+set cmd "valgrind --vgdb-error=0 $binfile"
 set res [remote_spawn host $cmd]
 if { $res < 0 || $res == "" } {
     verbose -log "Spawning $cmd failed."
@@ -43,18 +35,13 @@ pass $test
 # Declare GDB now as running.
 set gdb_spawn_id $res
 
-# GDB spawned by `valgrind --db-attach=yes' stops already after the startup is
-# executed, like with non-extended gdbserver.  It is also not correct to
-# run/attach the inferior.
+# GDB started by vgdb stops already after the startup is executed, like with
+# non-extended gdbserver.  It is also not correct to run/attach the inferior.
 set use_gdb_stub 1
 
 set test "valgrind started"
 # The trailing '.' differs for different memcheck versions.
 gdb_test_multiple "" $test {
-    -re "valgrind: Unknown option: --db-attach=yes" {
-	unsupported $test
-	return -1
-    }
     -re "Memcheck, a memory error detector\\.?\r\n" {
 	pass $test
     }
@@ -72,23 +59,63 @@ gdb_test_multiple "" $test {
 	unsupported $test
 	return -1
     }
+    -re "valgrind: Bad option.*--vgdb-error=0" {
+	# valgrind is not >= 3.7.0.
+	unsupported $test
+	return -1
+    }
+}
+
+set test "vgdb prompt"
+# The trailing '.' differs for different memcheck versions.
+gdb_test_multiple "" $test {
+    -re "  (target remote | \[^\r\n\]*/vgdb \[^\r\n\]*)\r\n" {
+	set vgdbcmd $expect_out(1,string)
+	pass $test
+    }
 }
 
+# Do not kill valgrind.
+set valgrind_spawn_id [board_info host fileid]
+unset gdb_spawn_id
+set board [host_info name]
+unset_board_info fileid
+
+clean_restart $testfile
+
+# Make sure we're disconnected, in case we're testing with the
+# native-extended-gdbserver board, where gdb_start/gdb_load spawn
+# gdbserver and connect to it.
+gdb_test "disconnect" ".*"
+
+gdb_test "$vgdbcmd" " in \\.?_start .*" "target remote for vgdb"
+
+gdb_test "monitor v.set gdb_output" "valgrind output will go to gdb.*"
+
 set double_free [gdb_get_line_number "double-free"]
 
-set test "attach to debugger"
-gdb_test_multiple "" $test {
-    -re "Invalid free\\(\\).*: main \\(${srcfile}:$double_free\\)\r\n.*---- Attach to debugger \\? --- \[^\r\n\]* ---- " {
-	send_gdb "y\r"
+set test "continue"
+gdb_test_multiple "continue" $test {
+    -re "Invalid free\\(\\).*: main \\(${srcfile}:$double_free\\)\r\n.*$gdb_prompt $" {
+	pass $test
+    }
+    -re "Remote connection closed.*\r\n$gdb_prompt $" {
+	fail "$test (remote connection closed)"
+	# Only if valgrind got stuck.
+	kill_wait_spawned_process $valgrind_spawn_id
+	return -1
     }
-    -re "---- Attach to debugger \\? --- \[^\r\n\]* ---- " {
-	send_gdb "n\r"
-	exp_continue
+    -re "The program is not being run\\.\r\n$gdb_prompt $" {
+	fail "$test (valgrind vgdb has terminated)"
+	# Only if valgrind got stuck.
+	kill_wait_spawned_process $valgrind_spawn_id
+	return -1
+    }
+    -re "\r\n$gdb_prompt $" {
+	pass "$test (false warning)"
     }
 }
 
-gdb_test "" ".*" "eat first prompt"
-
 # Initialization from default_gdb_start.
 gdb_test_no_output "set height 0"
 gdb_test_no_output "set width 0"
@@ -97,3 +124,6 @@ gdb_test "bt" "in main \\(.*\\) at .*${srcfile}:$double_free"
 
 # Explicitly kill the program so it doesn't dump core when we quit->detach.
 gdb_test "kill" "" "kill program" "Kill the program being debugged.*y or n. $" "y"
+
+# Only if valgrind got stuck.
+kill_wait_spawned_process $valgrind_spawn_id

  reply	other threads:[~2018-10-25 10:09 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20181024111355.GA13788@delia>
2018-10-24 16:29 ` Pedro Alves
2018-10-24 19:34   ` Tom de Vries
2018-10-24 20:50   ` Philippe Waroquiers
2018-10-25 10:09     ` Tom de Vries [this message]
2018-10-25 12:16       ` Pedro Alves
2018-10-25 14:26         ` [PATCH OB][gdb/testsuite] Move valgrind-db-attach.{c,exp} to valgrind-bt.{c,exp} Tom de Vries
2018-10-25 15:08         ` [PATCH][gdb/testsuite] Factor out lib/valgrind.exp Tom de Vries
2018-10-25 15:25           ` Pedro Alves
2018-10-25 20:03             ` Philippe Waroquiers

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=a1c8bbef-47a7-d120-b0b3-ce2b9b66575c@suse.de \
    --to=tdevries@suse.de \
    --cc=gdb-patches@sourceware.org \
    --cc=palves@redhat.com \
    --cc=philippe.waroquiers@skynet.be \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox