[PATCH glibc 3/3] rseq registration tests (v10)

[Mathieu Desnoyers]

----- On May 27, 2020, at 11:21 AM, Florian Weimer fweimer@redhat.com wrote:

> * Mathieu Desnoyers:
> 
>> ----- On May 27, 2020, at 11:12 AM, Florian Weimer fweimer@redhat.com wrote:
>>
>>> * Mathieu Desnoyers:
>>> 
>>>>>>>> +  retpid = TEMP_FAILURE_RETRY (waitpid (pid, &status, 0));
>>>>>>>> +  if (retpid != pid)
>>>>>>>> +    {
>>>>>>>> +      FAIL_EXIT1 ("waitpid returned %ld, expected %ld",
>>>>>>>> +                  (long int) retpid, (long int) pid);
>>>>>>>> +    }
>>>>>>> 
>>>>>>> Hmm.  Is the TEMP_FAILURE_RETRY really needed?  Our xwaitpid does not
>>>>>>> have this.
>>>>>>
>>>>>> Then how does it deal with a signal interrupting the system call performing
>>>>>> the waitpid (EINTR) ? I do not see WNOHANG being used.
>>>>> 
>>>>> It obscures spurious signals.  In most test cases, if an unexpected
>>>>> signal is delivered, something is quite wrong indeed.  This is why we
>>>>> don't generally hide EINTR errors.
>>>>
>>>> So it means you may have trouble using tools like strace and gdb on those
>>>> tests ? AFAIU those are heavy users of SIGSTOP and SIGCONT. Similarly for
>>>> profilers, those usually rely on a timer-driven signal.
>>> 
>>> I have never seen any problems with strace due to this.  ptrace has
>>> become a bit more transparent to the tracee since the early days, I
>>> think.
>>> 
>>> I haven't seen problems under GDB, either, but then tests that fork can
>>> be rather annoying to debug anyway.
>>
>> OK so I'll use the xwaitpid wrapper and let this be someone else's problem.
> 
> Yes please.  Or support_isolate_in_subprocess.

Right, even better, thanks,

Mathieu


-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com