LPT versus nptl

More problems with running LTP against nptl (PCC64). When we try to run 
LPT most kernel tests fail with the message:

WARN : signal() failed for signal 32. error: 22 Invalid argument.
WARN : signal() failed for signal 33. error: 22 Invalid argument.

The root cause is that ltp/lib/tst_sig.c(tst_sig) sets up a signal 
handler for each signal, except for specific signals where that is not 
allowed. The problem is that which signals are "reserved" and how this 
is enforced at runtime differs for linuxthreads and nptl.

For linuxthreads LTP tries to use the following:

         /*
          * pthread-private signals SIGPTINTR and SIGPTRESCHED.
          * Setting a handler for these signals is disallowed when
          * the binary is linked against libpthread.
          */
#ifdef SIGPTINTR
                 case SIGPTINTR:
#endif /* SIGPTINTR */
#ifdef SIGPTRESCHED
                 case SIGPTRESCHED:
#endif /* SIGPTRESCHED */

	            break;

The first problem being that niether SIGPTINTR or SIGPTRESCHED is 
defined, anywhere. However LPT does not fail for linuxthreads since it 
does not enforce any restriction on int __pthread_sig_restart, 
__pthread_sig_cancel, and __pthread_sig_debug unless the application is 
actually threaded? (pthread__sigaction is envoked dynamically via 
libc_maybe_call2, I think?)

NPTL defines SIGCANCEL and SIGTIMER in the private header pthreadP.h 
which is not available applications at compile time. But NPTL builds a 
./signal/sigaction.o which aggressively enforces the restriction on 
application use of SIGCANCEL and SIGTIMER! (even when the application is 
  not threaded yet???)

The solution not obvious to me. Since NPTL is agressive in its 
enforcement, LPT will have to be aware of the which library it is linked 
to. A compile time test would be useful (PTHREAD_LINUXTHREADS vs 
PTHREAD_NPTL). If that is not acceptable then LTP will have to use the 
runtime test proposed in in: 
https://listman.redhat.com/pipermail/phil-list/2003-April/000866.html

However either solution still begs the guestion of how LTP will know the 
range of signals to avoid ...