This is the mail archive of the archer@sourceware.org mailing list for the Archer 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: ptrace improvement ideas


Hi Roland,

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

	linux_nat_core_of_thread_1 (/proc/%d/task/%ld/stat)
	-> 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:
http://sourceware.org/bugzilla/show_bug.cgi?id=10729
http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/gdbserver/linux-x86-low.c.diff?cvsroot=src&r1=1.20&r2=1.21

(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
(NOTABUG RH#660003).


[...]
> 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.



Thanks,
Jan


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