This is the mail archive of the 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: [RFC] Set process affinity in test to work around ARM ptrace bug

On 07/25/2016 02:22 PM, Yao Qi wrote:
> Ping.


Hmm.  Seeing that the kernel fix was backported to so many
stable releases (positively) surprised me.  In that case, I question
the testsuite workaround a bit harder.  If this was a workaround in
gdb or gdbserver themselves, then it be more clear to me that the workaround
would be going to a broad set of users for whom updating the kernel is not easy.

But since this is only for when running the testsuite alone, I could argue that
this masks the problem and thus makes it look like gdb works better on an
affected system than it really does.  I think if I were working on gdb/gdbserver
on arm, I'd much prefer if gdb told me my system had a broken ptrace, so I
could act on it, rather than masking it off and pretend all is well.
How about we make gdb / gdbserver detect bad kernel version, and output a
warning to the effect?  We already have precedent in nat/linux-ptrace.c.
I think we should probably do that regardless of any testsuite workaround.

How bad would it be to push for people to update their kernels?

>From a testsuite workaround angle, instead of sprinkling 
set_process_affinity calls around, what if we we added a new proc
that would be called at the top of the .exp files:

gdb_caching_proc skip_arm_vfp_tests {} {

  if arm && linux && broken linux versions {
     return 1
  return 0

This would skip tests instead of making them pass, but how bad would
that be?  I assume that people doing gdb development/testing on arm will
be able to update their kernels, and will very much want to do that.

Pedro Alves

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