lkml.org 
[lkml]   [2011]   [Jun]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCHSET ptrace] ptrace: implement PTRACE_SEIZE/INTERRUPT and group stop notification, take#4
Date
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


\
 
 \ /
  Last update: 2011-06-03 12:27    [W:0.089 / U:0.900 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site