This is the mail archive of the
mailing list for the GDB project.
Re: [patch 2/3] attach-fail-reasons: Say more than ptrace: Operation not permitted.
- From: Pedro Alves <palves at redhat dot com>
- To: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Thu, 08 Mar 2012 13:55:22 +0000
- Subject: Re: [patch 2/3] attach-fail-reasons: Say more than ptrace: Operation not permitted.
- References: <20120306061710.GB24004@host2.jankratochvil.net>
On 03/06/2012 06:17 AM, Jan Kratochvil wrote:
> +linux_ptrace_attach_warnings (pid_t pid)
> + pid_t tracerpid;
> + tracerpid = linux_proc_get_tracerpid (pid);
> +extern pid_t linux_proc_get_tracerpid (int lwpid);
Would be neater with `pid_t lwpid'.
I agree this is a useful addition.
linux_ptrace_attach_warnings has a tiny race, in that by the time you open /proc/pid/... you
may be looking at a different process. There's no way to fix that, I think, and this
will be right in the large majority of the cases, so we can just live with it, IMO.
You may have considered the following already, but I haven't seen it mentioned. I think it
may be better if the new warning strings are actually part of the thrown error string:
- for example, frontends that display the error to the user as a dialog
box or similar show the whole warning+error automatically, instead of having the warning
get lost in the console noise (if it's visible at all).
- It's perhaps better for gdbserver as well, as we can forward the whole error string
to GDB so that GDB shows it to the user (the `E.' thing) (although we could forward warnings as
well with the O packet, though we don't do that presently).
- If some code in GDB, or most likely a python script, wraps "attach", and catches the error,
it presumably will also want to capture the warnings. Having everything in the
exception seems cleaner.
(Note this is not an objection. Your patch is useful as it is.)