[PATCH v2] Improve ptrace-error detection on Linux targets

[Pedro Alves]

On 9/4/19 8:31 PM, Sergio Durigan Junior wrote:
> I forgot to say, but the way my patch works now prevents the code path
> above to be executed.  My patch catches the ptrace failure very early in
> gdbserver initialization the process, when linux_child_function is
> called during the execution of linux_check_ptrace_features.  Since
> linux_child_function will try to perform a PTRACE_TRACEME (and fail if
> there are any restrictions in place), gdbserver will error out before it
> even tries to spawn/attach.
> 
> Nevertheless, during my tests I bypassed linux_check_ptrace_features and
> confirmed that the error message from linux_attach (above) is correctly
> displayed:
> 
>   [sergio@fedora-rawhide build]$ sleep 120 &
>   [5] 2732388
>   [sergio@fedora-rawhide build]$ ./gdb/gdbserver/gdbserver :9911 --attach 2732388
>   gdbserver: linux_ptrace_test_ret_to_nx: Cannot PTRACE_TRACEME: Operation not permitted
>   gdbserver: linux_ptrace_test_ret_to_nx: status 256 is not WIFSTOPPED!
>   gdbserver: linux_ptrace_test_ret_to_nx: failed to kill child pid 2732391 No such process
>   Cannot attach to process 2732388: 
> 
>   The SELinux 'deny_ptrace' option is enabled and preventing GDB
>   from using 'ptrace'.  You can disable it by executing (as root):
> 
>     setsebool deny_ptrace off
> 
>   The Linux kernel's Yama ptrace scope is in effect, which can prevent
>   GDB from using 'ptrace'.  You can disable it by executing (as root):
> 
>     echo 0 > /proc/sys/kernel/yama/ptrace_scope
> 
>   Exiting

So if you _don't_ hack linux_check_ptrace_features, what does the user
see, with either

        gdbserver [OPTIONS] --attach COMM PID

or extended-remote + "(gdb) attach" ?

Thanks,
Pedro Alves