This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: libffi on OpenBSD x86
- From: espie at quatramaran dot ens dot fr (Marc Espie)
- To: green at redhat dot com
- Cc: gcc at gcc dot gnu dot org
- Date: Thu, 21 Oct 2004 00:57:34 +0200 (CEST)
- Subject: Re: libffi on OpenBSD x86
- Organization:
- References: <mzyhpmsg.fsf@python.net>
In article <1098279488.3042.8.camel@localhost.localdomain> you write:
>On Wed, 2004-10-20 at 06:00, Thomas Heller wrote:
>> but it seems the stack smashing protection that OpenBSD uses prevents
>> ffi_call from working correctly.
>> I found the -fno-stack-protector command line option for gcc, and
>> specifying this did the trick.
>>
>> Now I'm not sure if there is a pragma which allows to disable the stack
>> protector from within the C source file, or should it be added to
>> libffi/configure somehow, or is there a way to pass this switch when
>> running libffi/configure?
>
>IIRC, this flag comes from a set of third-party GCC patches. It would
>certainly be easiest for the maintainer of those patches to cover the
>libffi directory as well.
>Alternatively, you can try setting CFLAGS_FOR_TARGET at the top-level
>when you make libffi.
As far as I know, Etoh Hiroaki has made a try, in the past, to see
if ProPolice could possibly be integrated in gcc.
This has not been successful yet. At times, it can be hard to integrate
stuff in the FSF tree of gcc. Especially when one doesn't speak good
english. What are the current plans about stack protection in gcc ?
I heard through the grapevine, that maybe, the inferior Stackguard might
make its way into the gcc mainstream (ProPolice is designed to be very
effective, yet only to add protections to functions which need it. We
have consistently timed it to <1% performance decrease with respect
to the non-ProPolice version).
As far as using ProPolice within OpenBSD has gone, I can tell you it is
quite a lot of work. ProPolice by itself works just fine, but it tends
to exercise bugs in the RTL generation elsewhere...
As far as I know, the ABI changes are straightforward: ProPolice affects
the way local automatic variables are stored on the stack, by putting
arrays at the end and protecting them with a canary. This is not
an ABI change, since it only affects the local function, and not the
way it calls other functions.