what is TCB_WAITEXECVE for?

[Luming Yu]

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

--Luming
---------- 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
> things.
>
> 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:

#ifdef LINUX
# 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 */
# endif

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?