rr is not compatible with valgrind

[khuey]

@pnkfelix reports that attempting to record valgrind with rr triggers an internal rr assertion.

After a brief investigation, valgrind is unmapping librrpreload.so at https://sourceware.org/git/?p=valgrind.git;a=blob;f=coregrind/m_initimg/initimg-linux.c;h=4da9a8b9760b42f98e6634ea9d83954d9caf1d0b;hb=HEAD#l913. This then causes AutoRemoteSyscalls to die next time we try to inject a syscall. This would seem to be fallout from @Keno's make-librrpreload-act-like-the-VDSO work from a while back.

I'm not sure what the motivation for valgrind's behavior is. Perhaps it could check for RUNNING_UNDER_RR in the env and not do that. Regardless, adding a break to skip the code in that case does get valgrind to record and replay successfully (admittedly valgrinding a very simple program).

[Keno]

Could we just reject munmap requests for that memory range on the rr side?

[rocallahan]

https://sourceware.org/git/?p=valgrind.git;a=commit;f=coregrind/m_initimg/initimg-linux.c;h=3a004915a2cbdcdebafc1612427576bf3321eef5

in this case just ignoring the munmap would work.

[khuey]

Another issue that came up today is that valgrind gets mad that we don't allow certain signals (SIGSTKFLT and SIGPWR) to be masked. In particular valgrind masks all signals (except SIGSTOP/SIGKILL) for every signal handler and when it changes the signal handler it asserts that those signals were masked on oldact.sa_mask.