[PATCH 5/5] Test attaching to a program that constantly spawns short-lived threads

[Breazeal, Don]

On 12/17/2014 4:02 PM, Pedro Alves wrote:

> diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp
> index 08087f2..83fa1d0 100644
> --- a/gdb/testsuite/lib/gdb.exp
> +++ b/gdb/testsuite/lib/gdb.exp
> @@ -3413,12 +3413,36 @@ proc gdb_exit { } {
>      catch default_gdb_exit
>  }
> 
> +# Return true if we can spawn a program on the target and attach to
> +# it.
> +
> +proc can_spawn_for_attach { } {
> +    # We use TCL's exec to get the inferior's pid.
> +    if [is_remote target] then {
> +	return 0
> +    }
> +
> +    # The "attach" command doesn't make sense when the target is
> +    # stub-like, where GDB finds the program already started on
> +    # initial connection.
> +    if {[target_info exists use_gdb_stub]} {
> +	return 0
> +    }
> +
> +    # Assume yes.
> +    return 1
> +}
> +
This solves the problem that I was working on here:

https://sourceware.org/ml/gdb-patches/2014-12/msg00520.html

When I call can_spawn_for_attach in the misbehaving attach tests I was
working on, they no longer spawn processes for 'target remote' that they
can't attach to.  Thanks!

>  # Start a set of programs running and then wait for a bit, to be sure
>  # that they can be attached to.  Return a list of the processes' PIDs.
> 
>  proc spawn_wait_for_attach { executable_list } {
>      set pid_list {}
> 
> +    if ![can_spawn_for_attach] {
> +	error "can't spawn for attach with this target/board"
> +    }

Should this be calling "error", or should it call something like
"untested" or "unsupported", since it isn't expected to work in these cases?

Thanks
--Don