Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Pedro Alves <palves@redhat.com>
To: Sergio Durigan Junior <sergiodj@redhat.com>,
	GDB Patches <gdb-patches@sourceware.org>
Cc: Eli Zaretskii <eliz@gnu.org>,
	Ruslan Kabatsayev <b7.10110111@gmail.com>,
	Tom Tromey <tom@tromey.com>
Subject: Re: [PATCH v5] Improve ptrace-error detection on Linux targets
Date: Thu, 26 Sep 2019 18:13:00 -0000	[thread overview]
Message-ID: <106c1a0b-1bdb-f139-26a1-5ec5d7304d9c@redhat.com> (raw)
In-Reply-To: <20190926042155.31481-1-sergiodj@redhat.com>

On 9/26/19 5:21 AM, Sergio Durigan Junior wrote:

> +
> +@smallexample
> +$ gdb program
> +...
> +Starting program: program
> +warning: Could not trace the inferior process.
> +Error:
> +warning: ptrace: Permission denied

This "Error:" above is stale, right?

> +There might be restrictions preventing ptrace from working.  Please see
> +the appendix "Linux kernel ptrace restrictions" in the GDB documentation
> +for more details.
> +During startup program exited with code 127.
> +(@value{GDBP})
> +@end smallexample
> +

> diff --git a/gdb/gdbserver/linux-low.c b/gdb/gdbserver/linux-low.c
> index d64c3641ff..c0e15c122f 100644
> --- a/gdb/gdbserver/linux-low.c
> +++ b/gdb/gdbserver/linux-low.c
> @@ -967,7 +967,8 @@ linux_ptrace_fun ()
>  {
>    if (ptrace (PTRACE_TRACEME, 0, (PTRACE_TYPE_ARG3) 0,
>  	      (PTRACE_TYPE_ARG4) 0) < 0)
> -    trace_start_error_with_name ("ptrace");
> +    trace_start_error_with_name ("ptrace",
> +				 linux_ptrace_me_fail_reason (errno).c_str ());

This code path is also run by a fork child.  So it needs the same pipe
treatment pointed out in v2 review, due to linux_ptrace_me_fail_reason not
being async-signal-safe.  It does not make sense to do the treatment in one
place and not on others.

>  /* Prepare to be traced.  */
>  
>  static void
> @@ -101,7 +115,8 @@ inf_ptrace_me (void)
>  {
>    /* "Trace me, Dr. Memory!"  */
>    if (ptrace (PT_TRACE_ME, 0, (PTRACE_TYPE_ARG3) 0, 0) < 0)
> -    trace_start_error_with_name ("ptrace");
> +    trace_start_error_with_name ("ptrace",
> +				 inf_ptrace_me_fail_reason (errno).c_str ());

Same here...

>  }
>  
>  /* Start a new inferior Unix child process.  EXEC_FILE is the file to
> diff --git a/gdb/inf-ptrace.h b/gdb/inf-ptrace.h
> index 98b5d2e09e..7cdab9af89 100644
> --- a/gdb/inf-ptrace.h
> +++ b/gdb/inf-ptrace.h
> @@ -83,4 +83,14 @@ protected:
>  
>  extern pid_t get_ptrace_pid (ptid_t);
>  
> +/* Pointer to "inf_ptrace_me_fail_reason", 

As pointed out before, this part of the comment does not make sense.
"inf_ptrace_me_fail_reason" is the name of the variable!

It's the same as saying this:

 /* Pointer to "ptr".  */
 int *ptr;

which is of course bogus.

Just say something like:

  /* Pointer to function that can be called by "inf_ptrace_me" (...)


which implements a function
> +   that can be called by "inf_ptrace_me" in order to obtain the reason
> +   for a ptrace failure.  ERR is the ERRNO value set by the failing
> +   ptrace call.
> +
> +   This pointer can be overriden by targets that want to personalize
> +   the error message printed when ptrace fails (see linux-nat.c, for
> +   example).  */
> +extern std::string (*inf_ptrace_me_fail_reason) (int err);
> +
>  #endif
> diff --git a/gdb/linux-nat.c b/gdb/linux-nat.c
> index cd5cf1830d..2c7ded7043 100644
> --- a/gdb/linux-nat.c
> +++ b/gdb/linux-nat.c
> @@ -1132,7 +1132,7 @@ attach_proc_task_lwp_callback (ptid_t ptid)
>  	  else
>  	    {
>  	      std::string reason
> -		= linux_ptrace_attach_fail_reason_string (ptid, err);
> +		= linux_ptrace_attach_fail_reason_lwp (ptid, err);
>  
>  	      warning (_("Cannot attach to lwp %d: %s"),
>  		       lwpid, reason.c_str ());
> @@ -1187,8 +1187,9 @@ linux_nat_target::attach (const char *args, int from_tty)
>      }
>    catch (const gdb_exception_error &ex)
>      {
> +      int saved_errno = errno;
>        pid_t pid = parse_pid_to_attach (args);
> -      std::string reason = linux_ptrace_attach_fail_reason (pid);
> +      std::string reason = linux_ptrace_attach_fail_reason (pid, saved_errno);
>  
>        if (!reason.empty ())
>  	throw_error (ex.error, "warning: %s\n%s", reason.c_str (),
> @@ -4567,6 +4568,10 @@ Enables printf debugging output."),
>    sigemptyset (&blocked_mask);
>  
>    lwp_lwpid_htab_create ();
> +
> +  /* Set the proper function to generate a message when ptrace
> +     fails.  */
> +  inf_ptrace_me_fail_reason = linux_ptrace_me_fail_reason;
>  }
>  \f
>  

> +static std::string
> +linux_ptrace_restricted_fail_reason (int err)
> +{
> +  if (err != EACCES && err != EPERM)
> +    {
> +      /* It just makes sense to perform the checks below if errno was
> +	 either EACCES or EPERM.  */
> +      return {};
> +    }
> +
> +  std::string ret;
> +  gdb_dlhandle_up handle;
> +
> +  try
> +    {
> +      handle = gdb_dlopen ("libselinux.so.1");
> +    }
> +  catch (const gdb_exception_error &e)
> +    {
> +      handle.reset (nullptr);

Nit, this line is unnecessary.  If an exception was thrown,
then handle was not writen to by the try block.

> +    }
> +

> --- a/gdb/remote.c
> +++ b/gdb/remote.c
> @@ -5825,8 +5825,20 @@ extended_remote_target::attach (const char *args, int from_tty)
>      case PACKET_UNKNOWN:
>        error (_("This target does not support attaching to a process"));
>      default:
> -      error (_("Attaching to %s failed"),
> -	     target_pid_to_str (ptid_t (pid)).c_str ());
> +      {
> +	std::string errmsg = rs->buf.data ();
> +
> +	if (!errmsg.empty ())
> +	  {
> +	    /* Get rid of the "E." prefix.  */
> +	    errmsg.erase (0, 2);
> +	  }
> +

What if the server just sends a regular numeric error, like "E01"?

> +	error (_("Attaching to %s failed%s%s"),
> +	       target_pid_to_str (ptid_t (pid)).c_str (),
> +	       !errmsg.empty () ? "\n" : "",
> +	       errmsg.c_str ());
> +      }
>      }
>  
>    set_current_inferior (remote_add_inferior (false, pid, 1, 0));
> 

Thanks,
Pedro Alves


  parent reply	other threads:[~2019-09-26 18:13 UTC|newest]

Thread overview: 98+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-19  3:29 [PATCH] " Sergio Durigan Junior
2019-08-19  9:10 ` Ruslan Kabatsayev
2019-08-19 13:47   ` Sergio Durigan Junior
2019-08-19 14:57     ` Ruslan Kabatsayev
2019-08-19 16:30     ` Christian Biesinger via gdb-patches
2019-08-19 17:04       ` Sergio Durigan Junior
2019-08-19 14:33 ` Eli Zaretskii
2019-08-25 22:38   ` Sergio Durigan Junior
2019-08-19 18:26 ` Pedro Alves
2019-08-25 22:40   ` Sergio Durigan Junior
2019-08-26 18:32 ` [PATCH v2] " Sergio Durigan Junior
2019-08-26 18:35   ` Christian Biesinger via gdb-patches
2019-08-26 20:51     ` Sergio Durigan Junior
2019-08-26 18:44   ` Eli Zaretskii
2019-08-29 14:40   ` Pedro Alves
2019-08-29 19:27     ` Sergio Durigan Junior
2019-08-29 19:48       ` Sergio Durigan Junior
2019-08-30 19:03         ` Pedro Alves
2019-08-30 19:51         ` [PATCH] Remove "\nError: " suffix from nat/fork-inferior.c:trace_start_error warning message Sergio Durigan Junior
2019-08-30 19:54           ` Pedro Alves
2019-08-30 21:06             ` Sergio Durigan Junior
2019-08-30 12:45       ` [PATCH v2] Improve ptrace-error detection on Linux targets Pedro Alves
2019-09-04 19:21         ` Sergio Durigan Junior
2019-09-04 19:31         ` Sergio Durigan Junior
2019-09-04 19:58           ` Pedro Alves
2019-09-04 20:21             ` Sergio Durigan Junior
2019-09-04 20:35               ` Pedro Alves
2019-09-04 20:56                 ` Sergio Durigan Junior
2019-09-04 21:23                   ` Pedro Alves
2019-09-04 21:36                     ` Sergio Durigan Junior
2019-09-05 12:19                       ` Pedro Alves
2019-09-05 17:58                         ` Sergio Durigan Junior
2019-08-30 12:47   ` Pedro Alves
2019-08-30 14:07     ` Eli Zaretskii
2019-08-30 19:44       ` Sergio Durigan Junior
2019-09-04 19:54 ` [PATCH v3] " Sergio Durigan Junior
2019-09-05 17:04   ` Eli Zaretskii
2019-09-11  1:11 ` [PATCH v4] " Sergio Durigan Junior
2019-09-12 12:39   ` Eli Zaretskii
2019-09-12 18:29     ` Sergio Durigan Junior
2019-09-24 20:40   ` Tom Tromey
2019-09-25 14:14     ` Sergio Durigan Junior
2019-09-25 22:04       ` Tom Tromey
2019-09-26  4:22         ` Sergio Durigan Junior
2019-09-26  4:22 ` [PATCH v5] " Sergio Durigan Junior
2019-09-26 17:32   ` Tom Tromey
2019-09-26 17:48     ` Pedro Alves
2019-09-26 17:51       ` Sergio Durigan Junior
2019-09-26 18:14         ` Pedro Alves
2019-09-26 18:25           ` Sergio Durigan Junior
2019-09-26 17:50     ` Sergio Durigan Junior
2019-09-26 18:13   ` Pedro Alves [this message]
2019-09-26 18:23     ` Sergio Durigan Junior
2020-02-26 20:06   ` [PATCH 0/6] Improve ptrace-error detection Sergio Durigan Junior
2020-02-26 20:06     ` [PATCH 6/6] Fix comment for 'gdb_dlopen' Sergio Durigan Junior
2020-02-26 20:23       ` Christian Biesinger via gdb-patches
2020-02-26 20:49         ` Sergio Durigan Junior
2020-02-28 15:21       ` Tom Tromey
2020-02-28 16:05         ` Sergio Durigan Junior
2020-02-26 20:06     ` [PATCH 3/6] Expand 'fork_inferior' to check whether 'traceme_fun' succeeded Sergio Durigan Junior
2020-02-26 20:06     ` [PATCH 5/6] Document Linux-specific possible ptrace restrictions Sergio Durigan Junior
2020-02-26 21:00       ` Ruslan Kabatsayev
2020-02-26 22:08         ` Sergio Durigan Junior
2020-02-26 20:06     ` [PATCH 2/6] Don't reset errno/bfd_error on 'throw_perror_with_name' Sergio Durigan Junior
2020-02-28 15:29       ` Tom Tromey
2020-02-28 16:36         ` Sergio Durigan Junior
2020-02-28 18:58           ` Tom Tromey
2020-02-28 19:50             ` Sergio Durigan Junior
2020-02-28 20:06         ` Pedro Alves
2020-02-28 20:35           ` Sergio Durigan Junior
2020-02-28 21:11             ` Pedro Alves
2020-03-02 20:07               ` Sergio Durigan Junior
2020-02-28 19:49       ` Pedro Alves
2020-02-28 20:01         ` Sergio Durigan Junior
2020-02-26 20:06     ` [PATCH 1/6] Introduce scoped_pipe.h Sergio Durigan Junior
2020-02-28 15:23       ` Tom Tromey
2020-02-28 16:08         ` Sergio Durigan Junior
2020-02-28 18:57           ` Tom Tromey
2020-02-28 19:48             ` Sergio Durigan Junior
2020-02-28 19:20       ` Pedro Alves
2020-02-28 19:47         ` Sergio Durigan Junior
2020-02-28 20:07           ` Pedro Alves
2020-02-26 20:06     ` [PATCH 4/6] Extend GNU/Linux to check for ptrace error Sergio Durigan Junior
     [not found]     ` <87v9nh3yme.fsf@redhat.com>
2020-03-15  4:21       ` [PATCH 0/6] Improve ptrace-error detection Sergio Durigan Junior
2020-03-15 21:16         ` Kevin Buettner
2020-03-17 15:47     ` [PATCH v2 0/5] " Sergio Durigan Junior
2020-03-17 15:47       ` [PATCH v2 1/5] Introduce scoped_pipe.h Sergio Durigan Junior
2020-03-17 15:47       ` [PATCH v2 2/5] Don't reset errno/bfd_error on 'throw_perror_with_name' Sergio Durigan Junior
2020-03-27 18:20         ` Pedro Alves
2020-03-17 15:47       ` [PATCH v2 3/5] Expand 'fork_inferior' to check whether 'traceme_fun' succeeded Sergio Durigan Junior
2020-03-27  4:14         ` Kevin Buettner
2020-03-27 13:06         ` Pedro Alves
2020-03-17 15:47       ` [PATCH v2 4/5] Extend GNU/Linux to check for ptrace error Sergio Durigan Junior
2020-03-27 15:28         ` Pedro Alves
2020-03-27 17:02         ` Kevin Buettner
2020-03-17 15:47       ` [PATCH v2 5/5] Document Linux-specific possible ptrace restrictions Sergio Durigan Junior
2020-03-20  0:53       ` [PATCH v2 0/5] Improve ptrace-error detection Kevin Buettner
2020-03-24 18:23         ` Sergio Durigan Junior

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=106c1a0b-1bdb-f139-26a1-5ec5d7304d9c@redhat.com \
    --to=palves@redhat.com \
    --cc=b7.10110111@gmail.com \
    --cc=eliz@gnu.org \
    --cc=gdb-patches@sourceware.org \
    --cc=sergiodj@redhat.com \
    --cc=tom@tromey.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox