what is TCB_WAITEXECVE for?
luming.yu at gmail.com
Thu Sep 18 02:02:58 UTC 2008
Could anybody here know what TCB_WAITEXECVE is, and why just x86
strace doesn't need this bit?
This bit has caused strace -f hang on ia64 (I guess there could be
seen on more Arch..)if child blocks SIGTRAP..
The issue has been discussed on kernel list for a long time...
---------- Forwarded message ----------
From: Luming Yu <luming.yu at gmail.com>
Date: Tue, Sep 16, 2008 at 4:50 PM
Subject: Re: [RFC PATCH] set TASK_TRACED before arch_ptrace code to fix a race
To: Roland McGrath <roland at redhat.com>
Cc: Petr Tesarik <ptesarik at suse.cz>, LKML
<linux-kernel at vger.kernel.org>, linux-ia64 at vger.kernel.org
On Wed, Sep 10, 2008 at 1:55 PM, Roland McGrath <roland at redhat.com> wrote:
> This subject line is quite far from what you're now addressing, btw.
> I certainly wouldn't recommend that patch. The interference between ptrace
> uses of SIGTRAP and a program that blocks SIGTRAP is just a fact of life
> with ptrace. If you wanted to change the exec SIGTRAP to be more
> consistent with other signals induced by debuggers (such as breakpoints and
> single-step), you could just change send_sig to force_sig. That unblocks
> SIGTRAP and resets its handler when it's blocked. Conversely, a tracer
> program could use PTRACE_O_TRACEEXEC if it cared to deal with tracing a
> process that blocks SIGTRAP. (That uses ptrace_notify rather than any
> actual signal that can be blocked.)
> But, none of this goes to your actual problem at all AFAICT. You've said
> your actual problem with strace only arises on ia64. The behavior of
> ptrace'd exec, and the effect of a program blocking SIGTRAP, is exactly the
> same across all machines. Changing it does not explain your situation.
> I'm in favor of understanding what is actually going on before changing
> If the SIGTRAP from exec is actually seen by strace on a different machine
> like it's not on ia64, that suggests that something different happened
> between the two. In the case that doesn't exhibit the problem, either
> SIGTRAP got unblocked by something before the exec, or userland (strace)
> behaves differently so that it doesn't care about not seeing that SIGTRAP.
The reason is not as complicated as I thought. It is because x86
strace don't test TCB_WAITEXECVE. please take a look at defs.h
(strace-4.5.16), the flag is defined as follows:
# if defined(ALPHA) || defined(SPARC) || defined(SPARC64) ||
defined(POWERPC) || defined(IA64) || defined(HPPA) || defined(SH) ||
defined(SH64) || defined(S390) || defined(S390X) || defined(ARM)
# define TCB_WAITEXECVE 02000 /* ignore SIGTRAP after exceve */
I'm not an strace expert, so I have no idea what the TCB_WAITEXECVE means.
And why x86 strace can handle SIGTRAP after execve but ALL other Arch can not..
Could anybody shield some lights on the flag?
More information about the Strace-devel