This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: alloca avoidance patches
- From: Jeff Law <law at redhat dot com>
- To: Joseph Myers <joseph at codesourcery dot com>, Florian Weimer <fweimer at redhat dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Mon, 19 Jun 2017 11:13:44 -0600
- Subject: Re: alloca avoidance patches
- Authentication-results: sourceware.org; auth=none
- Authentication-results: ext-mx06.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
- Authentication-results: ext-mx06.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=law at redhat dot com
- Dkim-filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 24B1741A5F
- Dmarc-filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 24B1741A5F
- References: <5a4e9615-8403-1854-a942-168bcd77d80b@redhat.com> <alpine.DEB.2.20.1706191644090.27712@digraph.polyomino.org.uk>
On 06/19/2017 10:47 AM, Joseph Myers wrote:
> It seems to me that we need a clear definition of what stack frame size
> glibc can assume is safe (so that we can aim to eliminate alloca and VLAs
> unless the compiler can see they are bounded, and use -Wstack-usage= for
> building glibc to make sure no function uses too much stack).
>
What we were thinking was a new -fstack-check implementation that
properly probes to avoid these problems (the existing -fstack-check is
fatally flawed for this stuff).
I've just posted an RFC around this issue to gcc-patches. I've actually
got code here that can be used to protect x86, ppc, s390 and aarch64
from this class of problems.
I'm pretty happy with the x86 and ppc specific bits. Less so with
aarch64 and s390. Michael Matz has some ideas on generic checking
that's less efficient, but easy to drop into the other target code
generators.
Jeff