How to port signal() to sigaction()?

Question

due to recent problems discovered with NDK12 and NDK13b2, i'm thinking of 'porting' libx264's use of signal() (and missing bsd_signal() in ndk12) to use sigaction() instead.

The problem is, I'm not quite sure what's the simple&fastest way to replace signal() calls with sigaction() ones.

For all i see, it's mainly used in x264-snapshot/common/cpu.c in the following manner:

using the following signal handler:

static void sigill_handler( int sig )
{
    if( !canjump )
    {
        signal( sig, SIG_DFL );
        raise( sig );
    }

    canjump = 0;
    siglongjmp( jmpbuf, 1 );
}

This is the problematic x264_cpu_detect function... currently, i'm guessing i only need to tackle the ARM version, but i';; still have to replace all occurances of signal() with sigaction() so i might just cover both of them to get the thing building...

FYI - the NDK13 beta2 still has "unstable" libc and the build doesn't fail on this part, but rather the first invocation of the rand() function somewhere else... So i'm out of luck and replacing the signal() calls might be better than just waiting for the official NDK13 release. I'm doing this to get rid of text-relocations so i can run the library (and doubango) on API 24 (Android N)

the problematic part of function that invokes signal():

#elif SYS_LINUX

uint32_t x264_cpu_detect( void )
{
    static void (*oldsig)( int );

    oldsig = signal( SIGILL, sigill_handler );
    if( sigsetjmp( jmpbuf, 1 ) )
    {
        signal( SIGILL, oldsig );
        return 0;
    }

    canjump = 1;
    asm volatile( "mtspr 256, %0\n\t"
                  "vand 0, 0, 0\n\t"
                  :
                  : "r"(-1) );
    canjump = 0;

    signal( SIGILL, oldsig );

    return X264_CPU_ALTIVEC;
}
#endif

#elif ARCH_ARM

void x264_cpu_neon_test( void );
int x264_cpu_fast_neon_mrc_test( void );

uint32_t x264_cpu_detect( void )
{
    int flags = 0;
#if HAVE_ARMV6
    flags |= X264_CPU_ARMV6;

    // don't do this hack if compiled with -mfpu=neon
#if !HAVE_NEON
    static void (* oldsig)( int );
    oldsig = signal( SIGILL, sigill_handler );
    if( sigsetjmp( jmpbuf, 1 ) )
    {
        signal( SIGILL, oldsig );
        return flags;
    }

    canjump = 1;
    x264_cpu_neon_test();
    canjump = 0;
    signal( SIGILL, oldsig );
#endif

    flags |= X264_CPU_NEON;

    // fast neon -> arm (Cortex-A9) detection relies on user access to the
    // cycle counter; this assumes ARMv7 performance counters.
    // NEON requires at least ARMv7, ARMv8 may require changes here, but
    // hopefully this hacky detection method will have been replaced by then.
    // Note that there is potential for a race condition if another program or
    // x264 instance disables or reinits the counters while x264 is using them,
    // which may result in incorrect detection and the counters stuck enabled.
    // right now Apple does not seem to support performance counters for this test
#ifndef __MACH__
    flags |= x264_cpu_fast_neon_mrc_test() ? X264_CPU_FAST_NEON_MRC : 0;
#endif
    // TODO: write dual issue test? currently it's A8 (dual issue) vs. A9 (fast      mrc)
#endif
    return flags;
}

#else

uint32_t x264_cpu_detect( void )
{
    return 0;
}

So the question is really this: what would be the quickest/easiest//fastest way to replace the signal() calls with sigaction() ones while preserving the current functionality?

EDIT: The reason i'm trying to get rid of signal() are these build errors:

/home/devshark/SCRATCH/doubango/thirdparties/android/armv5te/lib/dist/libx264.a(cpu.o):cpu.c:function sigill_handler: error: undefined reference to 'bsd_signal'

/home/devshark/SCRATCH/doubango/thirdparties/android/armv5te/lib/dist/libx264.a(cpu.o):cpu.c:function x264_cpu_detect: error: undefined reference to 'bsd_signal'
/home/devshark/SCRATCH/doubango/thirdparties/android/armv5te/lib/dist/libx264.a(cpu.o):cpu.c:function x264_cpu_detect: error: undefined reference to 'bsd_signal'

/home/devshark/SCRATCH/doubango/thirdparties/android/armv5te/lib/dist/libx264.a(cpu.o):cpu.c:function x264_cpu_detect: error: undefined reference to 'bsd_signal'

I already know that this is a known NDK12 problem, that might be solved by bringing bsd_signal back to the libc in NDK13. However, in it' beta state with it's unstable libc - it's currently missing the rand() function and simply waiting for it might not do the trick. But in the worst-case scenario, i guess i'll just have to wait for it and retry after it's release.

But as it currently is, the prebuilt version of the library i want to use has text-relocations and is being rejected by phones running newer API / version of the android OS.

EDIT2: I also know that signal() usually works by using sigaction() under the hood, but maybe i won't get bsd_signal related build-errors... since i'm suspecting that this one isn't using it. It's obviously using bsd_signal, which may or may not be the same underlying thing :/

Answer 1

According to info posted in your question, I see next points:

• You have prebuilt binaries, that were built for android-19 or lower (since they refer to bsd_signal()).

• You want to compile your code for android-21 or higher and link it against that old-targeted prebuilts.

As you may know, prior to android-21 a lot of libc's functions were declared as static just right in headers. And actually all they were thin wrappers around more generic functions, that are exposed by libc binaries. Old versions of NDK have next definition in <signal.h>:

/* the default is bsd */
static __inline__ __sighandler_t signal(int s, __sighandler_t f)
{
    return bsd_signal(s,f);
}

That is from where bsd_signal() references stand in your binaries. You have two choices how to solve it.

• Recompile your dependencies totally for android-21 or higher. But, note that they won't run on older platforms.

• Provide bsd_signal() in your code, e.g. you can add an extra source file with implementation of this function. You can use bionic's implementation as reference. Also note that this function should be marked as hidden: __attribute__ ((visibility ("hidden"))). This is needed to prevent putting it to DSO dynamic symbol table, that may confuse dynamic linker on old platforms that have that function already exposed by libc.so.

Also similar manipulations may be required for another libc functions, that previously were exported via similar static wrappers.

Note, that no one of the proposed two solutions requires modifications in the code of your dependencies.

Answer 2

The reason i'm trying to get rid of signal() are these build errors [...]

The code you present shows the functions in question calling signal(), whereas the linker errors indicate that they are calling bsd_signal() (directly). If the code presented goes with the error messages presented, then that can only mean that there is an in-scope macro or inline function whose expansion includes a call to bsd_signal(). Presumably, that macro is named signal(), so as to substitute for a call to the real signal() function.

If that's your macro / inline function then you should be able to fix it to call sigaction() instead (see below). On the other hand, if it is the system's macro / inline function then the system's header files do not correspond to its C library. In that case, it is essential to establish a consistent build environment before you do anything else.

So the question is really this: what would be the quickest/easiest//fastest way to replace the signal() calls with sigaction() ones while preserving the current functionality?

In order to answer that, one must first determine / divine what the current functionality is, or is supposed to be. POSIX allows the semantics of using signal() to set a signal's disposition to anything other than SIG_DFL or SIG_IGN to vary. Specifically, if you set a custom handler for a given signal then the disposition for that signal might or might not be reset to its default when the signal is received. Additionally, behavior varies with respect to whether the signal being handled is blocked during the execution of the handler. Resolving that issue was one of the primary purposes for introducing sigaction().

Supposing, based on the linker errors, that BSD behavior is what you are used to getting, the analog of

oldsig = signal( SIGILL, sigill_handler );

would be

struct sigaction old_action;
struct sigaction new_action = {
    .sa_handler = sigill_handler
};

int result = sigaction(SIGILL, &new_action, &old_action);
if (result) {
    // handle error ...
} else {
    oldsig = old_action.sa_handler;
}

If you want different semantics (emulating SysV signal() semantics, for instance) then you would use the sa_flags member of new_action to describe the details. If you want to mask any other signals while the handler runs, then you would want to use the sa_mask member to indicate that. In any case, you might also consider whether you need to preserve the flags or mask along with the previous handler.

You can substitute that for calling signal() by defining your own macro (not inline function) for signal(), after including all needed system headers. If your calls to signal() are spread across multiple files, then presumably you would want to put such a macro definition in a local header file.