I noticed that the test suite command logging would create a file like
"gdb.cmd.-1". I tracked this down to a substraction in
standard_output_file_with_gdb_instance.
Then, I saw that the .in file was not created for MI. This is fixed
by adding a call to default_mi_gdb_start.
Finally, commands might not end up in the .in file in some cases. For
me this happened because the test took a long time, so I got impatient
and killed it. Flushing the file after each write seemed like a good
thing to do here.
gdb/testsuite/ChangeLog
2020-10-26 Tom Tromey <tom@tromey.com>
* lib/mi-support.exp (default_mi_gdb_start): Call
gdb_stdin_log_init.
* lib/gdb.exp (standard_output_file_with_gdb_instance): Don't
subtract one from gdb_instances.
(gdb_stdin_log_write): Flush in_file.
+2020-10-26 Tom Tromey <tom@tromey.com>
+
+ * lib/mi-support.exp (default_mi_gdb_start): Call
+ gdb_stdin_log_init.
+ * lib/gdb.exp (standard_output_file_with_gdb_instance): Don't
+ subtract one from gdb_instances.
+ (gdb_stdin_log_write): Flush in_file.
+
2020-10-26 Tom de Vries <tdevries@suse.de>
* gdb.dwarf2/enqueued-cu-base-addr.exp: New file.
proc standard_output_file_with_gdb_instance {basename} {
global gdb_instances
- set count [expr $gdb_instances - 1 ]
+ set count $gdb_instances
if {$count == 0} {
return [standard_output_file $basename]
}
}
- #Write to the log
+ # Write to the log and make sure the output is there, even in case
+ # of crash.
puts -nonewline $in_file "$message"
+ flush $in_file
}
# Write the command line used to invocate gdb to the cmd file.
global MIFLAGS
global FORCE_SEPARATE_MI_TTY
+ # Keep track of the number of times GDB has been launched.
+ global gdb_instances
+ incr gdb_instances
+
+ gdb_stdin_log_init
+
if {[info exists FORCE_SEPARATE_MI_TTY]} {
set separate_mi_pty $FORCE_SEPARATE_MI_TTY
} else {