Re: [RFC] Set process affinity in test to work around ARM ptrace bug

[Pedro Alves <palves at redhat dot com>]

On 06/30/2016 02:57 PM, Yao Qi wrote:

> Then, I am thinking we can workaround this bug in testing, because the
> intermittent fails are confusing in comparing test results, by binding
> both tracer and tracee on the same core.  For example, we can start GDB
> or GDBserver with "taskset -c 0 ", but this is a global change, may
> have some affects on gdb.threads tests.
> I also think about doing
> "taskset -p PID -c 0" in test harness after the inferior is started,
> and do the same to the parent process of inferior (which is either GDB
> or GDBserver).
> 
> The approach in this patch is to have a small c function which sets
> both process affinity and its parent's affinity to core 0.  This
> function should be called in these tests explicitly, but other tests
> are not affected at all.  This patch is posted to get comments on the
> necessity of workaround this kernel bug, and the proper to workaround
> this bug.  There are still some test cases affected by this kernel bug,
> but this patch doesn't touch them yet.

Pushing people to update their kernels would be better, but I
understand how that's complicated on ARM, given that in many cases
it's not even possible to have access to the kernel's sources...

Still, it'd think that a fix in gdb/gdbserver itself would be
better  for _users_.

Also having to manually determine whether a test is misbehaving
because of this problem or not seems like recipe for continued pain.

I also think that whatever workaround, if any, should be limited
to known-broken kernels.  Otherwise, this is likely to mask
other problems going forward.  Maybe all we have is the version
number to work with, but that's still better than unconditionally
enabling this on arm.

Thanks,
Pedro Alves