[PATCH] Workaround a FreeBSD ptrace() bug with clearing thread events.

Maciej W. Rozycki macro@mips.com
Fri Mar 2 00:51:00 GMT 2018


On Fri, 23 Feb 2018, John Baldwin wrote:

> diff --git a/gdb/fbsd-nat.c b/gdb/fbsd-nat.c
> index d44950618c..9c87bfed33 100644
> --- a/gdb/fbsd-nat.c
> +++ b/gdb/fbsd-nat.c
> @@ -1163,6 +1163,39 @@ fbsd_resume (struct target_ops *ops,
>  	}
>        ptid = inferior_ptid;
>      }
> +
> +#if __FreeBSD_version < 1200052
> +  /*
> +   * When multiple threads within a process wish to report STOPPED
> +   * events from wait(), the kernel picks one thread event as the
> +   * thread event to report.  The chosen thread event is retrieved via
> +   * PT_LWPINFO by passing the process ID as the request pid.  If
> +   * multiple events are pending, then the subsequent wait() after
> +   * resuming a process will report another STOPPED event after
> +   * resuming the process to handle the next thread event and so on.
> +   *
> +   * A single thread event is cleared as a side effect of resuming the
> +   * process with PT_CONTINUE, PT_STEP, etc.  In older kernels,
> +   * however, the request pid was used to select which thread's event
> +   * was cleared rather than always clearing the event that was just
> +   * reported.  To avoid clearing the event of the wrong LWP, always
> +   * pass the process ID instead of an LWP ID to PT_CONTINUE or
> +   * PT_SYSCALL.

 Hmm, doesn't it have to be a run-time check then?  Otherwise you're 
basing your decision on the host system GDB has been built for and not one 
it will be run on, which I suppose does not necessarily have to be of the 
same version.  Or am I missing anything here?

  Maciej



More information about the Gdb-patches mailing list