Re: [PATCHv2] gdb: Fix instability in thread groups test

[Pedro Alves <palves at redhat dot com>]

On 08/13/2018 10:45 PM, Andrew Burgess wrote:
> Here's an updated version of the patch based on previous feedback.
> The new version has additional comments explaining why the regexp
> allows an empty core list.  I also only allow the empty core list
> when we scan all processes, its only in this case we might hit an
> exiting process.  When we scan two known PIDs, I don't allow an empty
> core list.

Thanks.

> +# The CORES_RE regexp allows a process to be running on zero or more
> +# cores.  This can happen if a process exits while GDB is reading
> +# information out of /proc.
> +set cores_re "cores=\\\[(\"$decimal\"(,\"$decimal\")*)?\\\]"

LGTM, except "this" is slightly ambiguous here.  Maybe:

 s/This can happen/The former can happen/

?

OK with that resolved.

Thanks,
Pedro Alves

>  
>  # List all available processes.
>  set process_entry_re "{${id_re},${type_re}(,$description_re)?(,$user_re)?(,$cores_re)?}"
> @@ -64,6 +68,12 @@ set spawn_id_2 [remote_spawn target $binfile]
>  set pid_2 [spawn_id_get_pid $spawn_id_2]
>  set id_re_2 "id=\"$pid_2\""
>  
> +# Unlike the earlier CORES_RE this list must contain at least one
> +# core.  Given that we know these processes will not exit while GDB is
> +# reading their information from /proc we can expect at least one core
> +# for each process.
> +set cores_re "cores=\\\[\"$decimal\"(,\"$decimal\")*\\\]"
> +
>  set process_entry_re_1 "{${id_re_1},${type_re}(,$description_re)?(,$user_re)?(,$cores_re)?}"
>  set process_entry_re_2 "{${id_re_2},${type_re}(,$description_re)?(,$user_re)?(,$cores_re)?}"
>  
>