Created attachment 50344 [details] [review]
cothreads.c gcc 4 build fix (untested)

Hi,

sparc/Linux doesn't have makecontext/getcontext and friends (they always fail)
and hence this code path is currently needed; is it still supported?

Hi,

I had a look at pth-2.0.4 since it seems this is where the m4 configure macro
comes from.  They have two MCSC (makecontext/setcontext) implementations, one
based on libc's makecontext/setcontext, the other based on sigsetjmp/setjmp.

AFAIUI, GStreamer has its own ASM implementation:
/***** Sun SPARC *****/
#define GST_ARCH_SET_SP(stackpointer) \
    __asm__( "ta 3\n\t" \
             "mov %0, %%sp" : : "r"(stackpointer));

#define GST_ARCH_CALL(target) \
    __asm__( "call %0,0\n\t" \
             "nop" : : "r"(target) );

#define GST_ARCH_PRESETJMP() \
    __asm__( "ta 3" );

Do you plan to support sparc in future releases?

Shouldn't GStreamer build-depend on pth?

Bye,

FYI, I've talked with people in the VideoLAN/VLC team and they base their
threads implementation on setjmp/sigsetjmp too and were not surprized to see
this problem arise with setcontext/makecontext/getcontext.

Loic, this code path is in practice never used, becuse we switched from
cothreads to a no-thread scheduler implementation ('opt').

We should still apply the patch because it fixes a build issue, but in practice
it won't make any difference.

Ok, so beside the makecontext-based code, there is this code, and a third code
(which you call the 'opt' scheduler implementation) and when this code is built,
it is not used, but the opt scheduler is, correct?

It seems this code is built since forever under Debian/sparc, so understanding
this issue in depth is necessary for me.

Yes, the code is built, but not used.

Closing as wontfix -- any "fix" here without extensive testing might braek on
other architectures, and we don't maintain this code any more. See justification
on bug #321824.