Re: ptrace improvement ideas (QPassSignals)

[Roland McGrath <roland@redhat.com>]

> An idea about another simple ptrace extension - to set a set of signals which
> are not interesting to GDB, like what exists in the gdbserver protocol:

That is another obvious feature.  It is straightforward to implement in the
kernel, but it requires some extra storage per-thread, which is clumsy in
the current kernel implementation.  As things are structured today, it's
hard to avoid bloating the kernel's main per-thread data structure by at
least a word (cost paid on every thread in the system even when ptrace is
not in use).  I'm not sure what the kernel community reaction to that would
be, though it might be acceptable.  It's already desireable to restructure
the ptrace implementation details so that ptrace-related storage is not
allocated when ptrace is not being used, but it's nontrivial to make such
changes.  They might happen in the future anyway.  But for those reasons
I did not include this as obvious low-hanging fruit.

It's also not clear to me how important that feature is in practice to GDB
users.  It's an obvious thing that we've all known about forever, but in my
recollections it is not very common to hear about a user complaining about
overhead of intercepting and passing on signals.  I suppose it is very
important to any application that is designed to generate and handle lots
of signals, but I'm not sure how often that comes up in practice.


Thanks,
Roland