This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Replacing malloc with alloca.

On 09/14/2015 02:14 AM, Richard Earnshaw wrote:
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.
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.

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]