This is the mail archive of the
mailing list for the Archer project.
Re: ptrace improvement ideas
- From: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- To: Roland McGrath <roland at redhat dot com>
- Cc: Project Archer <archer at sourceware dot org>, Oleg Nesterov <oleg at redhat dot com>
- Date: Mon, 7 Feb 2011 22:11:29 +0100
- Subject: Re: ptrace improvement ideas
- References: <20110203223905.D0C77180081@magilla.sf.frob.com>
the majority of the overhead should be solved by PTRACE_O_INHERIT, an idea for
a next optimization is to replace reading+parsing of "/proc/PID/xxx" text
files by a single syscall for that small binary value such as for:
linux_proc_pending_signals (/proc/PID/status) -> now 2x sigset_t
-> PTRACE_IS_SIGNUM_PENDING or PTRACE_GET_PENDING_SIGSET etc.
(GDB is only interested in SIGINT from that sigset_t now.)
-> PTRACE_GET_CPUCORE -> long return value as the CPU #
Also there could be PTRACE_SET_TGID_DEBUGREG to set debug registers for all
the TIDs of a PID (=TGID), even for those that are not stopped.
gdbserver now has to stop+resume each TID to change the hw watchpoints:
(issue 1) But what if some thread hits a hw watchpoint? Changing the debug
registers on x86* will make the result no longer readable.
(issue 2) Also it must set atomically at least both the DR_CONTROL and one of
DR addresses, best to set atomically all the 6 writable DR registers. But not
to set regular registers. PTRACE_POKEUSER writes a single register and other
block writes cannot write to DR registers.
There is already AFAIK some abstraction of DR regiters inside kernel so maybe
userland could get access to this abstraction to resolve these two issues.
On Thu, 03 Feb 2011 23:39:05 +0100, Roland McGrath wrote:
> * PTRACE_O_INHERIT
> Its effect is that clones of the tracee inherit the
> ptrace attachedness and option settings of their parent.
It must explicitly require debug registers (hw watchpoints) inheritance.
Which happened before but it no longer happens in recent upstream kernels
> To get this information reliably,
> the debugger needs to use the waitid call instead of waitpid/wait4.
[nitpick] or PTRACE_GETSIGINFO after waitpid, as GDB does.