[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