This is the mail archive of the
mailing list for the GCC project.
Re: Replacing malloc with alloca.
- From: Jeff Law <law at redhat dot com>
- To: Richard Earnshaw <Richard dot Earnshaw at foss dot arm dot com>, Florian Weimer <fw at deneb dot enyo dot de>
- Cc: Ajit Kumar Agarwal <ajit dot kumar dot agarwal at xilinx dot com>, Richard Biener <richard dot guenther at gmail dot com>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>, Vinod Kathail <vinodk at xilinx dot com>, Shail Aditya Gupta <shailadi at xilinx dot com>, Vidhumouli Hunsigida <vidhum at xilinx dot com>, Nagaraju Mekala <nmekala at xilinx dot com>
- Date: Mon, 14 Sep 2015 10:39:19 -0600
- Subject: Re: Replacing malloc with alloca.
- Authentication-results: sourceware.org; auth=none
- References: <37378DC5BCD0EE48BA4B082E0B55DFAA42990090 at XAP-PVEXMBX02 dot xlnx dot xilinx dot com> <87vbbenpga dot fsf at mid dot deneb dot enyo dot de> <55F5C6E8 dot 5040903 at redhat dot com> <87io7enn34 dot fsf at mid dot deneb dot enyo dot de> <55F681FE dot 1050700 at foss dot arm dot com>
On 09/14/2015 02:14 AM, Richard Earnshaw wrote:
Yes, but I suspect that eliminating a single malloc/free pair dwarfs the
cost of needing a frame pointer. The problem is proving when its safe
to turn a malloc/free into an alloca. As folks have shown, it's
non-trivial when the security aspects are considered.
On 13/09/15 20:19, Florian Weimer wrote:
* Jeff Law:
On 09/13/2015 12:28 PM, Florian Weimer wrote:
* Ajit Kumar Agarwal:
The replacement of malloc with alloca can be done on the following
If the lifetime of an object does not stretch beyond the immediate
scope. In such cases the malloc can be replaced with alloca. This
increases the performance to a great extent.
You also need to make sure that the object is small (less than a page)
and that there is no deep recursion going on. Otherwise, the program
may no longer work after the transformation with real-world restricted
stack sizes. It may even end up with additional security issues.
You also have to make sure you're not inside a loop. Even a small
allocation inside a loop is problematical from a security standpoint.
You also need to look at what other objects might be on the stack and
you have to look at the functional scope, not the immediate scope as
alloca space isn't returned until the end of a function.
Ah, right, alloca is unscoped (except when there are variable-length
Using a VLA might be the better approach (but the size concerns
remain). Introducing VLAs could alter program behavior in case a
pre-existing alloca call, leading to premature deallocation.
You also have to consider that code generated for functions containing
alloca calls can also be less efficient than for functions that do not
call it (cannot eliminate frame pointers, for example). So I'm not
convinced this would necessarily be a performance win either.
I've speculated that from a security standpoint that projects ought to
just ban alloca, particularly glibc. It's been shown over and over
again that folks just don't get it right and its ripe for exploitation.
It'd be a whole lot easier to convince folks to go this direction if
GCC was good about that kind of optimization.