This is the mail archive of the gdb-patches@sourceware.org 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: [patch 2/3] attach-fail-reasons: Say more than ptrace: Operation not permitted.


On 03/06/2012 06:17 AM, Jan Kratochvil wrote:

> +void
> +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.)

-- 
Pedro Alves


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