[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CABBv4TYgD3vyJYNhip3xEu49FsJ7BRso740TNNVqvnA_gjVxkw@mail.gmail.com>
Date: Sun, 08 Nov 2015 06:46:32 +0000
From: Petr Hosek <phosek@...omium.org>
To: musl@...ts.openwall.com
Subject: Re: [PATCH] don't define SHARED macro in the source
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 7, 2015 at 4:58 PM Rich Felker <dalias@...c.org> wrote:
> 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
>
Content of type "text/html" skipped
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
