We do distinguish between PIC and non-PIC but only during translation from bitcode down to native code when we link in the startup bits which have be built as native binary. However, this part is handled separately from the C library.
I got rcrt1.o building even with the SHARED macro by cherry-picking some of the recent Clang changes related to inline asm handling into our compiler, so this patch can be discarded. We don't really need rcrt1.o but as long as we can build it, I don't mind it being there so the extra option is probably not necessary.
Regarding cancellation, we handle these cases through intrinsics. We do have signals but they're somewhat different from POSIX signals.
On Sat, Nov 07, 2015 at 11:24:56PM +0000, Petr Hosek wrote:
> We don't support static pie in our toolchain so I haven't really tested
> that scenario but now I see why the SHARED macro is needed here.
>
> One option around this issue would be to avoid building rcrt1.c altogether,
> but I'd like to avoid carrying an extra patch for that. The other option
> would be to allow inline assembly in this case since it seems to be only
> used as a guard. I'll see if the second option is feasible.
As part of this release cycle, I plan to, by default, use the same .o
files (built as PIC) for both libc.so and libc.a, and remove the
SHARED macro. --disable-pic would then both imply --disable-shared and
inhibit building of rcrt1.o. I could add a separate
--disable-static-pie if you want to be able to use PIC but not static
pie (not generate rcrt1.o) and your arch could force all of these, but
my guess is that there's no such thing as PIC vs non-PIC for pnacl and
it's some kind of higher-level byte code. Anyway, does that sound
reasonable?
BTW, how are you doing cancellation without asm?
Rich