Messages in this thread | | | From | Pedro Alves <> | Subject | Re: [PATCHSET ptrace] ptrace: implement PTRACE_SEIZE/INTERRUPT and group stop notification, take#4 | Date | Fri, 3 Jun 2011 11:25:15 +0100 |
| |
On Friday 03 June 2011 02:24:45, Tejun Heo wrote: > > > * What to do about events which are reported by genuine SIGTRAP > > > generation? > > > > I don't understand what you meant here. Example(s)? > > The syscall, breakpoint, single step SIGTRAPs which can't be > distinguished from userland generated SIGTRAPs and may be mixed and/or > lost. Maybe it's best to leave them alone or maybe we can add some > way to distinguish them which is mostly backward compatible (which is > enabled w/ SEIZE and hopefully doesn't require noticeable userland > changes).
Some archs started encoding some of that stuff on SIGTRAPs si_code. E.g., on a ppc box I got here, I see:
/* `si_code' values for SIGTRAP signal. */ enum { TRAP_BRKPT = 1, /* Process breakpoint. */ # define TRAP_BRKPT TRAP_BRKPT TRAP_TRACE /* Process trace trap. */ # define TRAP_TRACE TRAP_TRACE };
It'd be _very_ useful for x86 (and others) to have something like TRAP_BRKPT for int3. Both for ptracers and in-process self debuggers.
I'd be super happy to be told we have that already in recent kernels and I missed it. :-)
-- Pedro Alves
| |