This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH 2/2] Fix PR gdb/20418 - Problems with synchronous commands and new-ui


On 16-08-02 07:21 PM, Pedro Alves wrote:
> +proc do_test {sync_command} {
> +    global srcdir subdir binfile srcfile
> +    global gdb_spawn_id gdb_main_spawn_id mi_spawn_id inferior_spawn_id
> +    global gdb_prompt mi_gdb_prompt
> +
> +    mi_gdb_exit
> +
> +    if {[mi_gdb_start "separate-mi-tty"] != 0} {
> +	fail "Could not start gdb"
> +	return
> +    }
> +
> +    mi_delete_breakpoints
> +    mi_gdb_reinitialize_dir $srcdir/$subdir
> +    mi_gdb_reinitialize_dir $srcdir/$subdir

This line is there twice.

> +    mi_gdb_load $binfile
> +
> +    # Start a synchronous run/continue on the MI UI.
> +    set test "send synchronous execution command"
> +    if {$sync_command == "run"} {
> +	if {[mi_run_cmd] >= 0} {
> +	    pass $test
> +	} else {
> +	    return
> +	}
> +    } else {
> +	if {[mi_runto main] < 0} {
> +	    return
> +	}
> +	if {[mi_send_resuming_command_raw "123-exec-continue" $test] >= 0} {
> +	    pass $test
> +	} else {
> +	    return
> +	}
> +    }
> +
> +    # Send -thread-info immediately after.  If everything works
> +    # correctly, this is only serviced by GDB when the execution
> +    # stops.
> +    send_gdb "456-thread-info\n"
> +    pass "send -thread-info"
> +
> +    # Make sure we trigger an asynchronous event (=thread-group-added)
> +    # in the separate MI UI.  Note the "run" variant usually triggers
> +    # =thread-group-started/=thread-created/=library-loaded as well.
> +    with_spawn_id $gdb_main_spawn_id {
> +	gdb_test "add-inferior" "Added inferior 2"
> +    }
> +
> +    # Interrupt the program.
> +    with_spawn_id $gdb_main_spawn_id {
> +	set test "interrupt on the CLI"
> +	gdb_test_multiple "$test" "$test" {

This uses "interrupt on the CLI" for both the command and the message.  I guess it works
because interrupt doesn't complain about arguments it doesn't know about.

> +	    -re "$gdb_prompt " {
> +		gdb_test_multiple "" "$test" {
> +		    -re "received signal SIGINT" {
> +			pass $test
> +		    }
> +		}
> +	    }
> +	}
> +    }
> +
> +    # On the MI channel, we should see the interrupt output _before_
> +    # the -thread-info output.
> +    with_spawn_id $mi_spawn_id {
> +	mi_expect_interrupt "got MI interrupt output"
> +    }
> +
> +    # Look for the result of our -thread-info.  If input were
> +    # re-enabled too soon, the thread would still be running.

Maybe say "appear to be running in the -thread-info output" or something like
that.  Otherwise it implies that the thread would still be running at this point in
time in the test.

But in general it looks good to me, even though the fine details escape my comprehension.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]