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: [RFA] gdbserver/lynx178: spurious SIG61 signal when resuming inferior.



On 05/13/2013 11:46 AM, Joel Brobecker wrote:
>         (lynx_resume): If PTID is null, then try using
>         current_process()->private->last_wait_event_ptid.

> @@ -260,6 +284,19 @@ lynx_resume (struct thread_resume *resume_info, size_t n)
>                         ? PTRACE_SINGLESTEP : PTRACE_CONT);
>    const int signal = resume_info[0].sig;
>  
> +  /* If given a null_ptid, then try using the current_process'
> +     private->last_wait_event_ptid.  On most LynxOS versions,
> +     using any of the process' thread works well enough, but
> +     LynxOS 178 is a little more sensitive, and triggers some
> +     unexpected signals (Eg SIG61) when we resume the inferior
> +     using a different thread.  */
> +  if (ptid_equal (ptid, minus_one_ptid))
> +    ptid = current_process()->private->last_wait_event_ptid;
> +
> +  /* The ptid might still be NULL; this can happen between the moment
> +     we create the inferior or attach to a process, and the moment
> +     we resume its execution for the first time.  It is fine to
> +     use the current_inferior's ptid in those cases.  */
>    if (ptid_equal (ptid, minus_one_ptid))
>      ptid = thread_to_gdb_id (current_inferior);
>  
> @@ -285,16 +322,6 @@ lynx_continue (ptid_t ptid)
>    lynx_resume (&resume_info, 1);
>  }

Nit, the comments above talk about null_ptid, while the code is
really checking for minus_one_ptid (wildcard).

Otherwise, if this is really what's necessary for Lynx178,
then this is OK.

-- 
Pedro Alves


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