[lldb][test] Wait for a file before attempting to attach to lldb-server test inferior (#162064)

Fixes #161510

Addresses the Linux parts of #138085

The situation we have to handle here is systems where Yama ptrace_scope
set to 1.

> 1 - restricted ptrace: a process must have a predefined relationship
>     with the inferior it wants to call PTRACE_ATTACH on. By default,
>     this relationship is that of only its descendants when the above
>     classic criteria is also met. To change the relationship, an
>     inferior can call prctl(PR_SET_PTRACER, debugger, ...) to declare
>     an allowed debugger PID to call PTRACE_ATTACH on the inferior.
>     Using PTRACE_TRACEME is unchanged.

(https://www.kernel.org/doc/Documentation/security/Yama.txt)

The inferior was addressing this by calling this at the start of main():
prctl(PR_SET_PTRACER, PR_SET_PTRACER_ANY, 0, 0, 0);

Which is ok if lldb-server tries to attach after that call has happened,
but there was nothing to synchronise this. So if the system was heavily
loaded, the inferior may be stalled, delaying the call, causing
lldb-server to fail to attach with EPERM (permission denied).

We were not using any mechanism to retry the attach or wait for some
signal from the inferior.

Except we do do this in other tests, even other lldb-server tests.

So I have adopted that mechanism to these tests:
* The inferior is launched with `syncfile:<path>` as its first argument.
* It creates this file at `<path>`, at a point where we know attaching
has been allowed.
* The test framework launches the inferior then waits for the file to
appear.
* This check is retried a few times, increasing the delay each time and
eventually giving up.
* Only once it has seen the file does it start lldb-server and tell it
to attach to the inferior.

I have tested this by insterting a `sleep()` call before the attach
enable call and running the test on a machine with ptrace_scope set to
1. I was able to increase the sleep to 6 seconds before tests failed
(when running just these tests, single threaded).

With OS scheduling, you could be stalled indefinitely, so we may have to
increase this timeout but this is easy to do with
wait_for_file_on_target.

The alternative is to have the test runner check ptrace_scope and only
enable these on systems where it's 0. Would be good to keep them running
if we can though.

0 files changed, 0 insertions, 0 deletions